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FROM  THE  SPONSOR 


Crosstalk  would  like  to  thank  DHS  for  sponsoring  this  issue. 


Each  person  and  organization  in  the  supply  chain  path  "touches," 
or  has  influence  on,  the  security  and  resilience  of  software  used 
to  control  products,  systems,  and  services. 

Just  as  with  food  and  pharmaceuticals,  software  can  be  corrupted  in  ways  that 
put  users,  organizations,  and  missions  at  risk.  Software  can  become  tainted  by 
\  y.  malware,  exploitable  weaknesses,  and  vulnerabilities.  But  no  matter  the  method  of 
compromise,  those  at  the  end  of  the  supply  chain  are  unwittingly  exposed  to  the 
residual  risk. 

Information  and  communications  technology  supply  chains  are  interdependent 
global  ecosystems  that  consist  of  organizations,  people,  activities,  information,  and 
resources.  And  these  complex  ecosystems  are  vulnerable  to  a  host  of  threats  and 
hazards  such  as  natural  disasters,  accidents,  and  malicious  attack.  Globalization  of 
the  commercial  information  and  communications  technology  marketplace  provides 
increased  opportunity  for  anyone  intent  on  harming  the  United  States  to  gain  unau¬ 
thorized  access  to  systems,  data,  and  communications.  Securing  the  global  supply 
chain  is  integral  to  securing  both  our  national  security  and  the  world  economy. 

The  government  and  private  sector  own  separate  parts  of  the  supply  chain  risk 
equation.  This  means  that  no  single  organization  independently  controls  all  the 
processes  or  possesses  all  the  information  required  to  manage  the  full  risk.  Public/ 
private  collaboration  is  crucial  to  supply  chain  risk  management. 

Our  Supply  Chain  Risk  Management  (SCRM)  program  promotes  the  improve¬ 
ment  of  formal  threat  sharing  processes,  planning  and  investment  documenta¬ 
tion,  supply  chain  incident  reporting,  national  security  systems  standards,  and  the 
Federal  cybersecurity  workforce. 

In  concert  with  the  DoD  and  NIST,  the  DHS  Software  Assurance  program  co¬ 
sponsors  a  forum  during  which  our  Federal,  academic,  and  private  sector  partners 
discuss  Software  Assurance  (SwA)  risks  and  mitigation  methods.  This  Software 
Assurance  Forum  has  contributed  several  excellent  resources  to  the  software  sup¬ 
ply  chain  risk  management  community.  These  resources  are  available  on  the  SwA 
Community  Resources  and  Information  Clearinghouse  at  <https://buildsecurityin. 
us-cert.gov/swa>. 

Venues  such  as  the  SwA  Forum  are  critical  to  our  understanding  of  how  suppli¬ 
ers  incorporate  security-aware  practices  into  the  production  of  software.  Baseline 
understanding  can  inform  risk-based  decisions  when  purchasing  software  or 
contracting  for  software-reliant  systems  or  services. 

This  issue  of  crosstalk  includes  articles  focused  on  advancing  SCRM  that  we 
hope  will  provide  valuable  insights  into  SCRM  techniques,  research  methods,  and 
models  that  target  vulnerabilities  in  the  supply  chain.  Thank  you  for  taking  advan¬ 
tage  of  this  excellent  resource. 


Roberta  Stempfley 

Acting  Assistant  Secretary 

Office  of  Cybersecurity  and  Communications 

Department  of  Homeland  Security 
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We  Cannot  Blindly  Reap 
the  Benefits  of  a  Globalized 
ICT  Supply  Chain! 

Don  Davidson,  Office  of  the  DoD  Chief  Information  Officer 
Stephanie  Shankles,  Booz  Allen  Hamilton 

Abstract.  Information  and  Communication  Technology  (ICT)  Supply  Chain  Risk 
Management  (SCRM)  seeks  to  manage  and  mitigate  cyber  and  supply  chain  risk 
throughout  an  acquisition  and  sustainment  lifecycle  for  an  element  or  a  system. 

It  is  a  multi-disciplinary  challenge  that  requires  contributions  and  collaboration 
among  many  disciplines.  Key  areas  include  systems  engineering,  system  security 
engineering,  information  security,  software  development,  application  security,  supply 
chain  and  logistics  planning  and  management,  IT  resiliency,  and  risk  management. 
While  many  areas  are  making  great  strides  in  developing  and  implementing  best 
practices  and  tools  to  combat  their  individual  cyber  challenges,  it  is  imperative  for 
successful  enterprise  risk  management  to  view  the  challenge  holistically  and  align 
common  best  practices  and  initiatives,  some  from/for  the  public  sector  and  some 
from/for  the  private  sector. 

Introduction 

A  holistic  view  of  supply  chain  risk  management  is  one  of 
the  12  key  areas  in  the  United  States  Comprehensive  National 
Cyber  Security  Initiative  (CNCI).  CNCI-SCRM  is  a  Federal  Gov¬ 
ernment  wide  multi-pronged  approach  for  managing  risk  while 
operating  in  a  global  supply  chain.  Managing  this  risk  requires 
a  greater  awareness  of  the  threats,  vulnerabilities,  and  conse¬ 
quences  associated  with  acquisition  decisions;  the  development 
and  employment  of  tools  and  resources  to  technically  and  op¬ 
erationally  mitigate  risk  across  the  lifecycle  of  systems,  products 
and/or  elements  (from  design  through  retirement);  the  develop¬ 
ment  of  new  acquisition  policies  and  practices  that  reflect  the 
complex  global  marketplace;  and  partnership  with  industry  to 
develop  and  adopt  supply  chain  and  risk  management  standards 
and  best  practices. 

“Software  and  hardware  are  at  risk  of  being  tam¬ 
pered  with  even  before  they  are  linked  together  in  an 
operational  system.  Rogue  code,  including  so-called 
logic  bombs,  which  cause  sudden  malfunctions,  can  be 
inserted  into  software  as  it  is  being  developed.  As  for 
hardware,  remotely  operated  “kill  switches”  and  hidden 
“backdoors”  can  be  written  into  the  computer  chips  used 
by  the  military,  allowing  outside  actors  to  manipulate  the 
systems  from  afar.  The  risk  of  compromise  in  the  manu¬ 
facturing  process  is  very  real  and  is  perhaps  the  least 
understood  cyberthreat.  Tampering  is  almost  impossible 
to  detect  and  even  harder  to  eradicate.” 

(DEPSECDEF  Lynn  in  FOREIGN  AFAIRS  in  Sep  2010.) 

Globalization  has  brought  a  unique  set  of  SCRM  challenges 
and  threats  to  the  U.S.  Government  and  industry,  especially 
with  our  ever-increasing  reliance  on  ICT  products  and  services 
to  meet  mission  and  business  needs  and  the  interconnected 


nature  of  our  IT  systems.  Threats  to  the  ICT  systems  are  varied, 
complex  and  demonstrate  a  wide  array  of  motivations  for  at¬ 
tack.  They  range  from  counterfeit  items  made  for  a  quick  profit, 
intentional  threats  such  as  malicious  code  or  hardware  Trojans, 
to  poor  software  development  practices  that  create  software 
vulnerabilities  or  hardware  quality  issues.  These  are  all  the  more 
dangerous  because  ICT  is  found  everywhere  in  our  environ¬ 
ment,  from  our  home  entertainment  systems,  mobile  devices 
that  hold/move  our  personal  information,  to  our  infrastructure’s 
financial  and  energy  sectors,  and  even  to  national  security  sys¬ 
tems  and  weapons  systems. 

Challenges  With  Globalization 

Globally,  USG  represents  a  relatively  minor  share  of  the  ICT 
product  and  service  market  for  the  industry  and  alone  does  not 
command  the  market  power  to  drive  commercial  suppliers  to 
substantially  change  their  SCRM  practices.  However,  USG  is 
an  important  stakeholder  in  the  process  because  of  their  role  in 
national  and  global  security  and  the  variety  of  valuable  lessons 
learned  and  best  practices  they  can  provide  because  they  are 
such  a  diverse  organization.  The  ICT  SCRM  challenge  is  not 
limited  to  USG,  it  impacts  every  government  and  commercial 
organization  that  acquires  and  uses  ICT  products  and  services. 
Furthermore,  many  of  the  suppliers  of  ICT  products  and  services 
also  find  themselves  acquiring  ICT  products  and  services  to 
integrate  into  their  own  solutions  and  therefore  have  a  common 
interest  in  facing  the  ICT  SCRM  challenge. 

Federal  acquirers  and  commercial  acquirers  and  suppliers  are 
all  increasingly  interconnected  and  interdependent  in  a  global 
supply  chain,  both  physically  and  digitally.  We,  in  USG  are  not  as 
independent  as  we  used  to  be;  we  have  fewer  unique  capabili¬ 
ties,  systems  and  components.  We  all  leverage  an  increasing 
number  of  COTS  products,  including  hardware,  software  and 
services.  However,  our  mission  remains  unique,  and  in  the  inter¬ 
est  of  national  security  and  warfighter  support,  mission  critical 
acquisitions  need  to  be  evaluated  in  terms  of  product  integrity, 
mission  assurance  and  SCRM  best  practices. 

In  this  budget-conscious  environment,  there  is  no  way  to  return 
to  a  supplier  base  of  “all-American”  companies  for  the  U.S.  Gov¬ 
ernment’s  ICT  acquisitions,  nor  can  we  have  complete  confidence 
that  even  American  made  products  are  free  of  supply  chain 
vulnerabilities.  Knowing  what  challenges  we  face  by  applying 
SCRM  practices  and  guidance  to  our  acquisition  processes  will 
help  us  tackle  our  next  big  challenge,  which  is  to  build  weapons 
systems  and  information  networks  that  are  resilient  against  the 
most  sophisticated  cyber  adversaries  using  mostly  commercial 
and  potentially  untrustworthy  products  and  services.  This  is  both  a 
sourcing  and  a  systems  engineering  challenge. 

Addressing  the  SCRM  Challenge 

GAO  recently  published  GAO  Report- 1 2-361  Code  31 1064, 
“IT  Supply  Chain:  National  Security-related  Agencies  Need  to 
Better  Address  Risks.”  They  endorsed  DoD  SCRM  strategy  and 
implementation  and  recommended  it  as  a  model  to  others.  The 
Committee  on  National  Security  Systems  (CNSS)  recently  pub¬ 
lished  CNSS  Directive  505  on  Supply  Chain  Risk  Management. 
GAO  said  DoD’s  efforts  to  implement  SCRM  can  be  a  learning 
tool  for  others  in  the  Federal  government.  DoD  is  currently  imple- 
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Figure  1 
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meriting  a  strategy  for  achieving  trusted  systems  and  networks  to 
address  this  challenge  which  has  four  key  tenets:  prioritizing  re¬ 
sources  based  on  mission  dependence;  comprehensive  program 
protection  planning;  enhanced  vulnerability  detection,  and  industry 
partnership.  This  trusted  systems  and  networks  strategy  is  being 
implemented  through  existing  Program  Protection  and  Informa¬ 
tion  Assurance  processes  through  the  recently  published  DoD 
policy  DoDI  5200.44  -  “Protection  of  Mission  Critical  Functions 
to  Achieve  Trusted  Systems  and  Networks.”  It  integrates  existing 
disciplines  of  SCRM,  system  security  engineering,  counterintel¬ 
ligence,  hardware  and  software  assurance  among  others,  to 
reduce  the  likelihood  that  warfighting  capabilities  will  be  impaired 
due  to  vulnerabilities  in  system  design  or  sabotage  of  a  system’s 
critical  functions  and  components.  The  policy  builds  on  best 
practices,  lessons  learned,  and  evolving  thinking  from  more  than 
four  years  of  piloting  and  incremental  implementation  within  the 
Department  by  requiring  specific  program  protection  and  SCRM 
activities  to  protect  the  most  critical  DoD  systems.  We  continue 
to  work  across  the  Department  and  with  our  fellow  interagency 
partners,  our  suppliers,  and  our  system  integrators  to  implement 
a  risk  management  strategy  into  other  government  organizations 
(and  their  suppliers)  and  the  country’s  wider  Critical  Infrastructure 
Protection  initiatives. 

As  we  develop  better  visibility  into  the  global  supply  chain  and 
improved  trust  in  the  products  we  consume  or  use  we  will  be 
able  to  develop  more  resilient  system  designs,  which  will  move 
us  from  a  “risk  response  posture”  to  a  more  proactive,  “risk  pre¬ 


vention,  risk  mitigation,  or  even  risk  endurance  posture.” 

In  Figure  1,  the  large  purple  arrow  highlights  information 
sharing  as  the  key  to  harmonizing  SCRM  efforts  currently  being 
addressed  by  different  stakeholders,  such  as  the  civil  govern¬ 
ment  agencies,  defense  agencies  and  private  industry.  A  number 
of  active  joint  efforts  and  information  sharing  forums  exist,  as 
noted  by  the  red  circled  items.  The  Open  Group’s  Open  Trusted 
Technology  Forum  is  a  collaborative  effort  between  govern¬ 
ment  and  industry  and  is  currently  developing  a  framework  of 
SCRM  best  practices  for  use  by  industry.  The  SCRM  Lifecycle 
Processes  and  Standards  Working  Group  meets  almost  monthly 
and  is  a  DHS-DOD  CNCI-1  1  (SCRM)  effort  co-chaired  by  DoD 
and  NIST  representatives  and  serves  as  an  interagency  sharing 
and  collaboration  venue.  The  Cyber  Security  1  (CS1)  ICT  SCRM 
Ad  Hoc  group  is  comprised  of  civil  and  defense/government 
representatives  and  industry  stakeholders.  The  primary  focus 
is  SCRM  input  and  development  of  international  standards,  as 
CS1  supports  the  International  Organization  for  Standardization 
(ISO).  Finally,  the  Common  Criteria  Development  Board  (CCDB) 
is  an  ISO  based  effort  supported  by  industry  and  government 
participation  and  is  actively  incorporating  SCRM  into  the  CC 
certifications  for  global  use. 

Working  With  Industry 

Product  development  (from  design  through  manufacturing, 
integration,  and  delivery)  typically  involves  an  array  of  develop¬ 
ers  and  suppliers  around  the  world,  many  of  whom  the  end  user 
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does  not  know.  As  a  consequence  of  our  global  supply  chain, 
adversaries  have  more  opportunities  to  corrupt  technologies 
before  we  take  ownership  and  introduce  malicious,  tainted  or 
counterfeit  code  or  hardware  into  the  supply  chain.  And  even 
outside  of  the  maliciously  altered  products,  these  incredibly 
complex,  commercial  products  may  at  times  have  vulnerabili¬ 
ties  unintentionally  left  in  as  they  leave  the  product  line.  These 
vulnerabilities  may  be  tolerable  in  cell  phones  and  video  games, 
but  could  prove  catastrophic  in  a  fighter  jet  or  classified  network 
as  such  vulnerabilities  may  make  it  easier  for  adversaries  to  use 
remote  access  attacks  to  otherwise  gain  access  to  the  USG’s 
systems  and  networks. 

DoD  has  been  working  internally  to  enhance  its  acquisition, 
engineering,  and  sustainment  processes,  while  simultaneously 
working  externally  with  commercial  industry  to  advocate  improved 
product  development  standards  to  reduce  vulnerabilities  in  com¬ 
mercial  products  related  to  global  sourcing.  The  study  of  ICT 
SCRM  standards  landscape  was  completed  in  January  201 0  in 
the  form  of  a  document  and  a  key  graphic  provided  in  Figure  2. 

The  graphic  and  the  corresponding  Standards  Landscape 
document  are  based  on  the  portfolio  of  two  international  commit¬ 
tees  under  the  auspices  of  ISO/I  EC  JTC1  -  SC  27  that  focuses 


on  IT  Security  Techniques  and  SC7  that  focuses  on  System  and 
Software  Engineering.  The  graphic  is  color-coded  as  follows: 

•  Blue  indicates  Standards  Development  Organization 
(SDO)  groups  associated  with  ISO,  I  EC,  or  ITU 

•  Green  indicates  other  SDOs 

•  Pink  indicates  US-based  organizations  including  the 
Technical  Advisory  Groups  for  SC7  (SC7  TAG)  and  SC27 
(CS1),  their  parent  organizations  (IEEE  and  ANSI),  as  well 
as  US  government  agencies  engaged  in  the  development 
of  ICT  SCRM  standards  (NIST,  DoD,  DHS) 

•  Purple  stars  indicate  specific  SDOs  currently  engaging 
in  the  development  of  ICT  SCRM  content,  both 
nationally  and  internationally,  including  SC27,  SC7,  The 
Open  Group,  CCDB,  and  NIST.  Note  these  same  starred 
areas  are  where  DoD  chose  to  engage  with  their 
information  sharing  activities. 

The  standards  landscape  identified  a  variety  of  groups  that 
are  engaging  in  the  collection/development  of  ICT  SCRM  or 
related  content  and  helped  prioritize  DOD  engagement  in  these 
groups,  as  well  as  the  areas  of  focus.  Based  on  the  outputs  of 
landscape  DOD  has  engaged  with  multiple  stakeholders  and 
continues  identifying  other  potential  stakeholder  groups  to  facili- 
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tate  information  sharing. 

The  standards  landscape  review  led  DOD  standardization 
activities  towards  specific  SDOs  to  focus  on  standardization 
for  ICT  SCRM.  The  standards  landscape  also  recommended 
relevant  standards  efforts  within  SC27  and  SC7  for  participation, 
influence,  and  monitoring  based  on  the  overall  DOD  engage¬ 
ment  framework.  DoD  is  actively  working  to  coordinate  external 
standards  efforts  with  the  DoD  IT  Standards  Registry. 

Based  on  the  landscape  DOD  focused  its  standardization 
on  CS1  and  worked  with  CS1  to  establish  and  Chair  CS1  ICT 
SCRM  Ad  Hoc  that  is  a  joint  group  with  SC7  TAG.  The  Ad  Hoc 
is  a  non-voting  group  that  has  the  authority  to  review  SC27  and 
SC7  standards  distributed  to  US  National  Bodies  (CS1  and  SC7 
TAG)  for  review  and  comment,  works  to  achieve  consensus  on 
a  single  position,  and  then  recommends  positions  for  vote  and 
approval  by  CS1  or  SC7  TAG  as  US  positions  to  be  submitted  to 
SC27  or  SC7. 

As  the  efforts  progressed,  other  areas  of  focus  were  identi¬ 
fied  including  The  Open  Group,  North  American  Security  Prod¬ 
ucts  Organization,  Information  Security  Forum,  Object  Manage¬ 
ment  Group,  Common  Criteria  /  IS0 1  5408  and  SAE(G  1 9),  etc. 
Trusted  Mission  Systems  and  Networks  continues  identifying 
additional  SDOs  for  potential  collaboration  through  the  current 
participation  in  various  SDOs.  These  efforts  were  identified 
based  on  the  inputs  received  from  individual  participants  in 
the  standardization  processes,  as  well  as  to  ensure  that  CS1/ 
SCRM  AdHoc  WG  references  relevant  documents  that  are 
either  already  in  the  standards  domain  or  in  the  process  of  be¬ 
ing  developed. 


Stakeholder 

Audience 

Ongoing  Effort 

Points  Of  Contact 

Department  of 

Defense 

T rusted  Systems  and 
Networks  Round  Table 

Joe  Wassel  -  joe.wassel@osd.mil 

Melinda  Reed  -  melinda.reed@osd.mil 

Interagency 

Coordination 

CNCI  SCRM  Working 
Group  2 

Don  Davidson  -  don.davidson@osd.mi 

Jon  Boyens  -  jon.boyens@nist.gov 

Critical  Infrastructure 
Protection 

DHS  SCRM 

DHS  Software  Assurance 

Joe  Jarzombek  -  joe.jarzombek@hq.dhs.gov 

ISO  Standards  and 
Harmonization 

CS1  ICT  SCRM  Ad  hoc 

Don  Davidson  -  don.davidson@osd.mil 

Nadya  Bartol  -  nadya.bartol@utc.org 

Table  1 :  SCRM  Effort  Contacts 

not  misunderstand  our  intent,  this  is  not  about  becoming  isola¬ 
tionists— DoD  embraces  globalization  and  will  continue  to  reap 
cost  and  schedule  benefits  from  it  every  day-but  we  do  need  to 
be  more  sensitive  to  the  system  and/or  information  security  and 
product  and/or  data  integrity  implications,  to  our  systems  and 
ultimately  our  capabilities,  when  outsourcing  key  components 
and  capabilities.  We  need  to  better  “see”  into  some  legs  of  the 
supply  chain,  especially  where  critical  components  are  involved. 

DoD  is  doing  well  in  our  strategy  and  implementation  on 
SCRM,  however  we  are  developing  capability  through  a 
“crawl-walk-run”  process  which  has  dependencies  on  potentially 
diminishing  resources  and  external  support,  like  private 
sector  cooperation. 

For  additional  information  or  to  get  involved  in  SCRM  efforts, 
contacts  are  listed  in  Table  1 .  ^ 


Conclusion 

The  SCRM  community/stakeholders  know  that  change  will 
not  happen  overnight  and  the  implementation  of  this  kind  of 
comprehensive  acquisition  risk  management  for  all  of  our  sys¬ 
tems  and  networks  will  take  the  investment  of  resources,  time 
and  funding.  Therefore  a  key  element  of  the  SCRM  strategy  is 
to  prioritize  capabilities  and  their  enabling  systems  and  sub¬ 
components;  identify  our  critical  systems  and  plan  for  and  build 
in  more  trust,  using  a  risk  based  approach. 

In  DoD  we  continually  seek  to  improve  our  capabilities  and 
cyber  posture;  improving  our  capability  to  detect  cyber  problems 
in  our  day-to-day  operations,  but  that  still  puts  us  in  a  “risk  re¬ 
sponse  posture”;  we  need  to  better  understand  the  components 
within  our  systems  that  enable  our  mission  critical  capabilities 
(we  call  this  criticality  analysis);  where  do  we  source  the  critical 
hardware,  software,  and  services  for  those  systems  (especially 
national  security  systems  and  critical  infrastructure),  and  how 
should  we  better  design  and  manage  our  systems  to  minimize 
vulnerabilities  and  assure  critical  functions,  even  when  a  system 
is  under  attack.  Understanding  and  managing  the  risk  associated 
with  those  systems  and  their  components,  will  make  us  and  our 
systems  more  resilient. 

Recently,  there  has  been  a  lot  of  news  on  microelectronic 
counterfeits,  malicious  or  poor  quality  software  and  data  breach¬ 
es.  All  of  these  topics  have  roots  in  our  global  supply  chain.  Do 
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Managing  Risk  in  the 
Software  Supply  Chain 
Through  Software 
Code  Governance 

Kristin  Brennan,  Coverity 

Abstract.  With  the  increasing  complexity  of  software  applications,  shrinking  IT 
budgets  and  the  spiraling  cost  of  developing  software,  many  organizations  in  both 
the  public  and  private  sectors  are  turning  to  third-party  software  suppliers  including 
outsourced  teams,  partners  and  open  source  to  develop  their  applications.  Accord¬ 
ing  to  a  recent  study  conducted  by  Forrester  Consulting  and  Coverity  [1  ],  almost  all 
organizations  are  using  some  form  of  third-party  code  in  their  products,  and  over 
40%  rely  on  software  from  three  to  five  different  software  suppliers. 


you  are  trying  to  establish  governance  across  internal  teams, 
with  outsourcers,  offshore  development  teams,  or  partners,  and 
whether  you  have  access  to  source  code  for  the  application. 

Establish  Acceptance  Criteria 

Automated  code  testing  solutions  enable  managers  to  establish 
and  enforce  consistent  measures  for  quality  and  security  across 
the  software  supply  chain.  Organizations  can  use  automated  code 
testing  to  establish  acceptance  criteria  with  their  suppliers.  For 
example,  it  could  be  mandated  in  the  contract  that  all  code  must  be 
tested  with  static  analysis.  Static  analysis  testing  produces  results 
that  are  repeatable,  measurable  and  objective.  To  support  static 
analysis  testing,  policies  can  be  automatically  established  to  ensure 
that  there  are  no  uninspected  defects  and  no  high  impact  quality 
and  security  defects  in  the  code.  A  strict  acceptance  criteria  can 
be  established  so  that  all  found  defects  must  be  addressed  before 
the  code  is  accepted.  This  approach  puts  the  onus  on  the  software 
supplier  to  ensure  their  code  is  of  high  enough  quality  to  pass  the 
established  acceptance  criteria  and  would  be  a  practical  solution  in 
situations  where  you  do  not  have  access  to  source  code. 


The  use  of  COTS  tools  in  military  environments  is  no  longer 
limited  to  hardware.  COTS  software  is  increasingly  making  its 
way  into  military  platforms.  In  systems  where  the  use  of  existing 
commercial  components  is  both  possible  and  feasible,  it  is  no 
longer  economically  feasible  for  the  government  to  specify,  build, 
and  maintain  a  large  array  of  comparable  proprietary  products. 

However,  commercial  third-party  code  is  typically  not  tested 
with  the  same  level  of  rigor  as  internally  developed  code.  As 
software  complexity  grows,  additional  software  capabilities  bring 
many  more  lines  of  code,  and  greater  opportunity  for  error.  That 
means  a  defect  could  be  lurking  in  the  third-party  code  that 
could  cause  a  significant  breach  or  security  issue. 

Organizations  are  recognizing  the  need  for  end-to-end 
accountability  for  the  quality  and  security  of  the  code  in  their 
products,  regardless  of  who  actually  created  the  code.  There  is 
a  need  for  efficient  processes  to  enforce  consistent  software 
code  governance  across  the  software  supply  chain. 

Software  Code  Governance 

The  initial  focus  of  software  code  governance  was  to  assure 
software  quality  and  security  of  in-house  developed  code  by 
establishing  clear  guidelines  and  procedures  such  as  the  FDA’s 
recommendation  that  infusion  devices  be  tested  with  static 
analysis  and  DO-1  78C,  Software  Considerations  in  Airborne 
Systems  and  Equipment  Certification  for  the  avionics  industry. 
Today,  we  see  software  code  governance  gaining  momentum 
in  a  wide  variety  of  industries  as  organizations  seek  to  drive 
greater  accountability  and  efficiency  within  distributed  devel¬ 
opment  teams  and  to  achieve  better  visibility  and  control  over 
third-party  code. 

A  Multi-Step  Process 

Software  code  governance  cannot  be  achieved  with  the  click 
of  a  button.  It  is  a  process  that  needs  to  be  embraced  by  the  or¬ 
ganization  and  enforced  across  the  internal  and  external  supply 
chain.  The  process  will  vary  by  organization  based  upon  whether 


Auditing  Mode 

Another  approach  to  ensuring  quality  and  security  across 
the  supply  chain  is  to  establish  auditing  rights  with  suppliers. 
Organizations  that  purchase  source  code  can  reserve  the  right 
to  analyze  the  supplier’s  code  and  report  back  results.  This  could 
be  implemented  as  part  of  the  integration  phase  of  the  lifecycle. 
This  auditing  right  helps  the  organization  measure  quality  in 
a  consistent  manner  across  their  supply  chain  and  with  their 
internal  teams.  It  also  enables  the  organization  to  provide  rec¬ 
ommendations  and  results  of  the  analysis  back  to  the  supplier 
giving  them  an  opportunity  to  fix  the  defects.  Once  a  baseline 
for  quality  and  security  has  been  established  with  a  supplier,  a 
policy  can  be  enforced  that  no  new  defects  are  allowed  as  new 
defects  could  introduce  risk  into  the  overall  project. 

Self-Certification 

Organizations  who  are  supplying  code  can  also  be  encour¬ 
aged  to  take  proactive  measures  to  “self-certify”  the  quality  of 
their  code  before  delivering  it.  NNG,  a  pioneer  of  navigation 
software  and  the  developer  of  iGO  Navigation  solutions  has 
adopted  such  an  approach  in  the  private  sector.  It  has  deployed 
static  analysis  to  deliver  high  quality  software  and  accelerate 
time-to-market  for  software  delivery  to  its  supply  chain.  NNG 
has  delivered  navigation  solutions  to  more  than  1 50  business 
customers  including  the  world’s  leading  original  equipment 
manufacturers.  Its  navigation  software  is  at  the  heart  of  millions 
of  products  from  in  vehicle  infotainment  systems  and  smart¬ 
phones  to  personal  navigation  devices. 

NNG  has  embedded  static  analysis  into  their  development 
process  so  every  new  line  of  code  is  tested  before  it  is  released 
into  the  market.  It  enables  them  to  track  and  manage  defects 
between  28  projects  and  different  code  branches  comprising 
over  1  million  lines  of  code.  As  a  result  of  development  testing, 
NNG  has  been  able  to  establish  standardized  metrics  for  mea¬ 
suring  software  quality  across  the  supply  chain  and  remove  cost 
and  complexity  from  its  own  software  development  activities. 
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Conclusion 

Establishing  and  enforcing  acceptance  criteria  and  negotiat¬ 
ing  the  right  to  audit  the  software  quality  are  two  concrete  steps 
organizations  can  take  to  maintain  the  highest  levels  of  quality 
across  their  software  supply  chain.  As  software  and  supply 
chains  continue  to  become  more  complicated,  and  organizations 
continue  to  deliver  more  innovation,  and  at  the  lowest  cost  pos¬ 
sible,  the  ability  to  enforce  consistent  standards  for  quality  will 
become  increasingly  important.^ 
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Homeland 

Security 


The  Department  of  Homeland  Security,  Office  of 
Cybersecurity  and  Communications,  is  seeking 
dynamic  individuals  to  fill  several  positions  in  the 
areas  of  software  assurance,  information  technology, 
network  engineering,  telecommunications,  electrical 
engineering,  program  management  and  analysis, 
budget  and  finance,  research  and  development,  and 
public  affairs. 


To  learn  more  about  the  DHS  Office  of  Cybersecurity 
and  Communications  and  to  find  out  how  to  apply  for 
a  vacant  position,  please  go  to  USAJOBS  at 
www.usajobs.gov  or  visit  us  at  www.DHS.GOV; 
follow  the  link  Find  Career  Opportunities,  and  then 
select  Cybersecurity  under  Featured  Mission  Areas. 


CALL  FOR  ARTICLES 

If  your  experience  or  research  has  produced  information  that  could  be  useful  to  others, 
Crosstalk  can  get  the  word  out.  We  are  specifically  looking  for  articles  on  software- 
related  topics  to  supplement  upcoming  theme  issues.  Below  is  the  submittal  schedule  for 

three  areas  of  emphasis  we  are  looking  for: 


Securing  the  Cloud 

Sep/Oct  2013  Issue 
Submission  Deadline:  April  10,  2013 

Real-Time  Information  Assurance 

Nov/ Dec  2013  Issue 
Submission  Deadline:  June  1 0,  201 3 


Please  follow  the  Author  Guidelines  for  Crosstalk,  available  on  the  Internet  at 
<www.crosstalkonline.org/submission-guidelines>.  We  accept  article  submissions  on 
software-related  topics  at  any  time,  along  with  Letters  to  the  Editor  and  BackTalk.  To  see 
a  list  of  themes  for  upcoming  issues  or  to  learn  more  about  the  types  of  articles  we’re 
looking  for  visit  <www.crosstalkonline.org/theme-calendar>. 
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How  International  Standard 
Efforts  Help  Address 
Challenges  in  Today's 
Global  ICT  Marketplace 


Stephanie  Shankles,  Booz  Allen  Hamilton 

Michele  Moss,  Booz  Allen  Hamilton 

Jed  Pickel,  Microsoft's  Trustworthy  Computing  group 

Nadya  Bartol,  Utilities  Telecom  Council 

Abstract.  An  increasingly  distributed  and  global  Information  and  Communication 
Technology  (ICT)  supply  chain  brings  challenges  to  U.S.  Government  and  industry. 
Identifying  and  mitigating  risks  involves  looking  beyond  your  organization  and  un¬ 
derstanding  and  managing  risks  caused  by  the  lack  of  visibility  in  the  ICT  supply 
chain.  Recent  research  indicates  that  current  ICT  supply  chain  risk  management 
practices  tend  to  have  a  tactical  focus  motivated  primarily  by  compliance  rather 
than  a  strategic  integrated  approach.  However,  there  are  a  number  of  exist¬ 
ing  international  standards  and  several  under  development  that  when  used  in 
combination  will  help  this  problem.  Using  these  standards  together  will  provide  a 
security  assurance  process  for  information  security  governance,  software  devel¬ 
opment,  Supply  Chain  Risk  Management  (SCRM),  and  should  result  in  reducing 
ICT  supply  chain  risk. 

Challenges  in  Today’s  Global  ICT  Marketplace 

ICT  supply  chain  risk  management  covers  both  software  and 
hardware.  Several  recent  industry  reports  focused  primarily  on 
software  and  on  the  general  state  of  information  security  pro¬ 
vide  insights  into  current  ICT  supply  chain  practices,  and  what 
motivates  their  selection: 

•  Software  Security:  Think  Big,  Start  with  What  Matters, 

2009  The  Burton  Group  [1], 

•  Cyber  Supply  Chain  Security  and  Software  Assurance 
Research  Report,  201 1  Enterprise  Strategy  Group  [2]. 

•  Borderless  Security:  Global  Information  Security  Survey, 

2010  Ernst  and  Young  [3]. 

•  State  of  Application  Security,  201 1  Forrester 
Consulting  [4]. 

•  Global  Information  Security  Workforce  Study, 

201 1  Frost  &  Sullivan  and  (ISC)2  [5]. 

•  Software  Integrity  Controls,  201 0  SAFECode  [6]. 

•  Assessing  SCRM  Capabilities  and  Perspectives  of  The 
IT  Vendor  Community:  Toward  a  Cyber-Supply  Chain 
Code  of  Practice,  2010  University  of  Maryland  [7]. 

•  Verizon  and  Secret  Service  (USSS)  -  Data  Breach 
Investigations  Report,  2010  and  201 1  [8] [9]. 


Together,  these  reports  present  the  following  key  findings 
in  Table  1 . 

Although  each  report  is  focused  on  different  aspects  of 
information  security  and  therefore  touches  on  different  aspects 
of  ICT  supply  chain  security,  they  share  a  common  message  that 
holistic  processes  are  needed  to  mitigate  risks.  Table  2  sum¬ 
marizes  the  results  of  three  studies,  which  while  conducted  at  a 
different  level  of  detail,  presented  similar  conclusions. 

It  is  evident  from  the  studies’  results  that  to  advance  the 
state  of  the  software  security  practice,  stakeholders  across  an 
organization  will  need  to  bridge  the  communication  gap  with 
the  purpose  of  effectively  balancing  the  executive  priorities  and 
the  implementation  of  operational,  technical,  and  management 
practices  for  software  security  and  supply  chain. 

The  Enterprise  Strategy  Group  study  [2]  identified  that  over 
40  %  of  the  surveyed  organizations  trust  their  developers  to 
know  how  to  develop  secure  software.  Several  key  trends 
emerged  from  this  and  other  studies  appear: 

1 .  Only  47%  of  acquirers  are  performing  acceptance  testing 
of  third  party  code.  As  a  result,  vulnerabilities  in  the  code  are  not 
identified  until  the  code  is  in  production  and  organizations  that 
acquired  this  software  are  left  with  the  consequences.  While  the 
problem  originated  in  the  software  supply  chain,  the  acquirers 
have  to  address  the  risk. 

2.  Compliance  requirements  to  run  scans  of  the  operations 
environment  result  in  the  identification  of  code  level  vulnerabili¬ 
ties.  Subsequently,  the  realization  of  insecure  coding  practices  is 
not  identified  as  an  issue  until  the  operations  and  maintenance 
phase  of  the  lifecycle,  when  it  is  more  difficult  and  costly  to  fix. 
Again,  the  problem  that  originated  in  the  software  supply  chain 
is  left  up  to  the  acquirer  to  address. 

3.  Shifting  from  responding  to  vulnerabilities  identified  during 
operations  to  preventative  practices  in  technology  acquisition 
and  development  takes  time  and  effort  (potentially  increasing 
time  to  deliver  and  cost  of  initial  product-even  though,  this  cost 
has  been  demonstrated  to  be  less  than  the  lifecycle  sustain¬ 
ment  costs  when  fixed  later).  With  46%  of  respondents  using  a 
development  method,  the  foundation  is  in  place  for  a  coordinat¬ 
ed  approach  to  maintaining  legacy  technology  and  minimizing 
the  impact  of  security  incidents. 

ICT  SCRM  Practices 

The  University  of  Maryland  (UMD)  and  the  Enterprise 
Strategy  Group  conducted  studies  focused  on  procedures  that 
organizations  use  to  manage  security  and  risk  in  their  supply 
chains  for  ICT  products  and  services.  Supply  chain  risk  manage¬ 
ment  is  one  of  the  initiatives  in  the  United  States  Comprehen¬ 
sive  National  Cyber  Security  initiative.  As  such,  it  has  been  the 
focus  of  discussion  and  study  by  a  number  of  organizations. 
However,  the  practice  of  securing  ICT  supply  chains  is  still  in 
its  infancy  and  is  often  a  misinterpreted  problem.  The  Septem¬ 
ber  201  1  article,  “Renewable  Industry  in  Turmoil  Latest  Sign: 
American  Superconductor  Accuses  Chinese  Firm— Its  Biggest 
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Key  Findings 

What  ICT  supply 
chain  practices 
organizations 
currently  employ? 

■  Security  practices  surrounding  software  development  are  tactical  in  nature  and 
do  not  address  software  security  risks  in  a  strategic  manner. 

■  Supply  chain  risk  management  practices  are  tactical  and  are  not  addressed  in  a 
strategic  manner. 

What  informs  and 
motivates  the 
selection  of  ICT 
supply  chain 
processes? 

■  The  largest  motivator  for  secure  software  development  practices  is  compliance 

■  Lack  of  leadership  support  and  resistance  to  changing  existing  software 
development  practices  is  a  barrier  to  the  adoption  of  secure  development 
methodologies. 

■  To  advance  the  state  of  the  software  security  practice,  stakeholders  across  an 
organization  will  need  to  bridge  the  communication  gap  to  effectively  balance  the 
executive  priorities  and  the  resources  needed  for  the  implementation  of 
operational,  technical,  and  management  practices  for  software  security  and 
supply  chain. 

■  40%  of  organizations  surveyed  do  not  employ  a  secure  software  program 
because  they  trust  their  developers  know  how  to  develop  secure  software  and/or 
don’t  believe  they  have  a  security  issue. 

Table  1 : 


VDBR 

(Verizon) 

Executive 
Perspective 
(Ernst  &  Young) 

Security  Professional 
Perspective 
(Frost) 

Common  Objective 

■  96%  of  breaches 
were  avoidable 
through  simple  of 
intermediate  controls 

■  Approximately  half  of 
the  breaches  utilized 
hacking  or  malware 

■  Increase  in  risk  due 
to  social  networking, 
cloud  computing  and 
personal  devices  in 
the  enterprise 

■  Data  leakage  is  the 
primary  concern  for 
organizations 

■  New  technologies 
are  boing  deployed 
without  adequate 
security 

■  Application 
vulnerabilities  are  the 
#1  threat  to 
organizations 

■  Implement  essential 
security  practices  (such  as 
access  control,  network 
management,  secure 
development,  and  log 
management/analysis)  to 
mitigate  the  risk  of  a  data 
breach  and  loss  of 
sensitive  data 

Table  2: 


Customer— of  Espionage”  in  the  Wall  Street  Journal  highlights 
[10]  several  facets  of  the  supply  chain  challenge  that  involved 
a  prominent  American  wind  turbine  manufacturer.  Proprietary 
software  was  stolen  and  given  to  a  major  Chinese  competitor. 

An  affiliate  of  the  competitor  was  a  major  Chinese  parts  supplier 
to  the  American  manufacturer  Superconductor.  It  appears  that 
the  American  manufacturer’s  supplier  was  intentionally  providing 
them  with  faulty  parts  and  components.  Not  only  was  American 
Superconductor  a  victim  of  a  malicious  insider,  they  were  also 
the  victim  of  supply  chain  tampering.  This  challenge  will  grow  as 
large  and  small  organizations  operate  in  increasingly  compli¬ 
cated  and  globally  dispersed  supply  chains. 


[It  appears  that  the  American  manufacturer's 

supplier  was  intentionally  providing  them  with  faulty 
parts  and  components.  Not  only  was  American 
Superconductor  a  victim  of  a  malicious  insider, 
they  were  also  the  victim  of  supply  chain  tampering. 
This  challenge  will  grow  as  large  and  small 
organizations  operate  in  increasingly  complicated 
and  globally  dispersed  supply  chains. 
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"American  Superconductor  Accuses  Chinese  Firm 


INCIDENT: 

An  employee  of  American  Superconductor  Corporation 
working  in  Austria  is  charged  with  stealing  and  modifying 
valuable  software  that  controls  turbines.  The  employee  gave 
the  software  to  Sinoval  Wind  Corporation,  the  Chinese 
company  that  is  under  contract  with  American  Superconductor. 
Sinvolal  then  passed  it  on  to  an  affiliate,  a  fierce  competitor  of 
American  Superconductor,  who  then  repackaged  it  and  sold  it 
back  to  Sinoval  at  a  very  low  cost. 


MITIGATION: 

Austrian  authorities  confirmed  that  they  have  arrested  the 
employee  and  he  is  cooperating.  American  Superconductor  is 
seeking  criminal  redress  through  Chinese  and  Austrian  courts 
and  the  Beijing  Arbitration  Commission.  They  claim  they  are 
owed  $250  million  for  breach  of  contract  claim. 


Figure  1 


—Its  Biggest  Customer— of  Espionage" 

IMPACT: 

The  stolen  software  has  already  appeared  in  turbines  sold  by 
Sinvoel  in  China.  It  has  given  the  Chinese  valuable  intellectual 
property  and  may  lead  to  huge  financial  losses  for  American 
Superconductor.  The  company  has  gone  from  $30  a  share  early  in 
the  year  to  about  $6  a  share  in  September,  falling  sharply  on  the 
news  of  legal  action. 


Mj 

; 

http://online.wsj.com/article/SB100014240531119033740045765789 

71052370768.html 


Common  Development  Practice: 

The  RuggedCom  Operating  System  (ROS)  contains  a  vulnerability 
that  could  allow  an  authenticated,  remote  attacker  to  access 
sensitive  information  on  a  targeted  device.  The  vulnerability 
exists  because  the  RSA  private  key  infrastructure  (PKI)  for  SSL 
communications  between  an  affected  device  and  the  user  is 
hard-coded  (visible)  in  the  affected  software.  An  authenticated, 
remote  attacker  could  exploit  this  vulnerability  by  reverse 
engineering  the  key  from  the  affected  software. 


Risk: 

The  vulnerability  allows  an  attacker  to  decrypt  any  SSL-based 
communications  between  an  end-user's  web  browser  and  the 
RuggedCom  device.  In  addition,  the  hard-coded  private  key 
could  be  used  in  a  man-in-the-middle  (MITM)  attack  to 
impersonate  a  RuggedCom  device  undetected.  A  successful 
exploit  could  lead  to  the  loss  of  system  integrity  and  lead  to 
additional  attacks.  Attackers  could  access  power  station 
communications,  intercept  sensitive  data  and  communications, 
and  even  potentially  take  control  of  critical  infrastructure 
systems. 


Operational  Impact: 

The  vulnerability  was  discovered  in  smart  grid  networking 
devices  produced  by  industrial  networking  equipment 
manufacturer  RuggedCom.  RuggedCom  manufactures  ethernet 
switches,  network  routers,  wireless  devices,  serial  servers, 
media  converters  and  other  communications  equipment  for 
use  in  harsh  electrical  and  climatic  environments  like  those 
found  in  electrical  power  substations,  oil  refineries,  military 
installations  or  roadside  traffic  control  cabinets. 


^RUGGEDCOM 

_J-..  INDUSTRIAL  STRENGTH  NETWORKS' 


•  http://www.computerworld.eom/s/artide/9230516/ICS  CERT  warns 

of  SSL  security  flaw  in  RuggedCom  industrial  networking  devices 

•  http://tools.cisco.com/securitv/center/viewAlert.x?alertld=26713 

•  http://www.smartplanet.com/blog/thinking-tech/new-securitv-flaw- 

uncovered-in-smart-grid-gear/12823 


Source:  Don  Davidson,  DOD-CIOTrusted  Mission  Systems  and  Networks 


Figure  2 
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Acquisition  and  Outsourcing 


Acquisition  Practice 

Vendor  Due  Diligence:  Only  10%  use  results  of  vendor  security  audits  to  make  procurement  decisions  (1) 
67%  use  personnel  security  reviews  (2) 

49%  use  standardized  process  for  pre-qualifying  suppliers  (2) 


(1)  Enterprise  Strategy  Group,  "Assessing  Cyber  Supply  Chain  Security 
Vulnerabilities  Within  the  U.S.  Critical  Infrastructure,"  November  2010 

(2)  NIST /  UMD,  "Assessing  SCRM  Capabilities  and  Perspectives  of  the  IT 
Vendor  Community:  Toward  a  Cyber-Supply  Chain  Code  of  Practice  " 


Product  Development  and  Maintenance 

•  Software  Development  Efforts:  68%  develop  a  significant 
or  some  of  their  own  software  for  internal  use  (1) 

•  Security  Best  Practices  (such  as  adding  firewalls,  use  of 
standards,  secure  system  development  lifecycle,  etc.): 

Less  than  50%  currently  use  these  activities  as  part  of  its 
software  development  (1) 

Prepare  for  the 
acquisition 


Advertise  and 
select  the  supplier 


Initiate  an 
agreement 


Monitor  the 
agreement 


Acceptance 


Operational 

System 


There  is  □  divide  between  small  and  large  companies  with  regard 
to  employing  security  measures  and  small  companies  are  falling 
behind.  However,  the  study  findings  suggest  that  incentives  can 
lead  to  positive  changes  in  this  area.  UMD  research  indicates  that 
smaller  organizations  are  highly  motivated  to  use  government 
cyber-SCRM  practice  guidelines. 


Figure  3 

Similar  to  the  security  practices  surrounding  software 
development,  currently  used  ICT  supply  chain  risk  management 
practices  are  also  tactical  and  are  not  addressed  in  a  strategic 
manner.  For  example,  procedures  that  allow  organizations  to 
understand  activities  of  suppliers,  such  as  auditing  vendor  prac¬ 
tices,  are  rarely  used.  When  audits  are  used,  organizations  rarely 
allow  those  results  to  influence  procurement  decisions. 

In  addition  to  identifying  that  about  40%  of  the  organi¬ 
zations  surveyed  do  not  employ  a  secure  software  program 
because  they  trust  their  developers  know  how  to  develop  secure 
software  and/or  do  not  believe  they  have  a  security  issue,  the 
Enterprise  Strategy  Group  study  [2]  also  indicated  that  most  de¬ 
velopment  efforts  are  not  employing  essential  security  practices. 
The  Verizon  Data  Breach  Report  identified  similar  issues. 

According  to  the  UMD  study  [7],  there  is  a  divide  between 
small  and  large  companies  with  regard  to  employing  security 
measures  and  small  companies  are  falling  behind.  However, 
the  study  findings  suggest  that  incentives  can  lead  to  posi¬ 
tive  changes  in  this  area.  UMD  research  indicates  that  smaller 
organizations  are  highly  motivated  to  use  government  cyber- 
SCRM  practice  guidelines.  Many  of  the  smaller  organizations 
view  this  as  an  opportunity  to  gain  acceptance  into  the  federal 
acquirer  community.  Likewise,  larger  organizations  view  SCRM 
practice  guides  as  a  means  of  differentiating  themselves  by 
making  these  practices  a  “condition  of  membership”  in  a  premier 
industry  organization. 

International  Standards  Environment  and  ICT  SCRM 

The  issues  and  challenges  identified  in  the  reports  can  be  ad¬ 
dressed  by  applying  several  existing  and  emerging  international 
standards.  Figure  4  illustrates  the  relationship  between  existing 
and  emerging  ISO  standards  that  provide  the  framework  for  ad¬ 
dressing  ICT  SCRM  concerns  evident  from  the  various  studies. 


The  Overview  layer  in  the  figure  depicts  three  overview  stan¬ 
dards  that  address  the  overall  information  security  management 
(ISO/IEC  27000),  information  security  in  supplier  relation¬ 
ships  (ISO/IEC  27036-1),  and  application  security  (ISO/IEC) 
27034-1 .  Collectively  these  standards  provide  the  fundamentals 
and  vocabularies  for  these  three  disciplines.  The  Requirements 
layer  depicts  the  two  relevant  requirements  standards.  ISO/ 

I  EC  27001  provides  requirements  for  managing  information  se¬ 
curity  for  the  enterprise  using  a  risk-based  approach.  ISO/IEC 
27036-2  provides  requirements  to  be  used  to  protect  enterprise 
information  when  working  with  suppliers  or  acquirers.  Finally, 
the  Guidance  layer  depicts  the  guidance  standards  associated 
with  the  requirements  standards  above.  ISO/IEC  1 5288/1 2207 
(Systems  and  software  engineering-System  lifecycle  processes 
and  Systems  and  software  engineering— Software  lifecycle 
processes)  acknowledges  integration  of  both  ISO/IEC  27036 
and  ISO/IEC  27034  with  system  and  software  engineering 
standards.  ISO/IEC  27036-3  provides  specific  guidance  on  ICT 
supply  chain  security  in  addition  to  the  requirements  in  ISO/IEC 
27036-2.  ISO/IEC  27002  provides  guidance  for  implement¬ 
ing  security  controls  selected  as  a  result  of  a  risk  assessment 
required  by  27001.  It  should  be  noted  that  of  these  standards, 
ISO/IEC  27036  is  in  draft,  while  the  rest  are  published  stan¬ 
dards.  ISO/IEC  27001  and  27002  are  currently  under  revision. 
These  standards  provide  processes,  controls,  and  practices  for 
resolving  many  of  the  issues  identified  earlier. 
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Figure  4 


Information  Security  Management  Governance 

The  ISO/I  EC  27000  family  of  standards  provides  a  number 
of  standards  for  establishing  and  implementing  an  information 
security  management  system.  Specifically,  ISO/IEC  27001,  In¬ 
formation  Security  Management  System  Requirements,  provides 
a  governance  framework  for  information  security.  Implementing 
this  framework  will  help  gain  leadership  support  for  approaching 
the  challenges  of  today’s  global  marketplace  such  as  imple¬ 
menting  appropriate  operational,  technical,  and  management 
practices  for  software  security  and  supply  chain. 

ICT  Supply  Chain 

While  there  are  a  number  of  published  standards  that  can  help 
organizations  manage  information  security  and  associated  risks, 
none  of  those  currently  published  standards  provides  guidance  on 
how  to  protect  an  organization’s  information  security  interests  in 
a  relationship  between  acquirers  and  suppliers.  ISO/IEC  27036 
which  is  currently  in  draft,  provides  an  approach  for  protecting  sen¬ 
sitive  enterprise  data  within  the  context  of  acquiring  and  supplying 
products  and  services.  This  multipart  standard  covers  managing  the 
information  security  aspects  of  a  portfolio  of  supplier  relationships, 
as  well  guidance  for  how  to  manage  individual  supplier  relation¬ 
ships.  The  standard  provides  requirements  that  cover  a  broad  vari¬ 
ety  of  products  and  services,  as  well  as  context-specific  guidance. 
Specifically,  Part  3  focuses  on  ICT  supply  chain  security. 

The  standard  introduces  a  number  of  requirements  and  con¬ 
cepts  that  while  not  new  in  supply  chain  and  sources  contexts, 
are  new  in  the  information  security  context: 

•  Having  a  registry  (inventory)  of  all  suppliers. 

•  Assigning  responsible  individuals  to  manage  information 
security  aspects  of  relationships  with  each  supplier. 

•  Assessing  the  criticality  of  such  relationships  and 
associated  risks  and  using  this  criticality  to  prioritize 
supplier  relationships  and  associated  security  requirements. 


•  Having  a  minimal  set  of  information  security  requirements 
applicable  to  any  supplier  relationship. 

•  Monitoring  the  information  security  aspects  of  supplier 
relationships. 

•  Ensuring  protection  of  data  and  information  when 
terminating  those  relationships. 

Software  Development  Security  Practices 

Secure  software  development  practices  are  important  to  sup¬ 
ply  chain  security  risk  management  efforts.  The  Forrester  study 
referenced  earlier  in  this  article  provides  a  good  basis  for  under¬ 
standing  potential  risks  from  software  development  process  gaps. 
Results  of  the  study  are  concisely  summarized  in  the  statement: 
“While  a  majority  of  organizations  have  implemented  some  form  of 
application  security  measures,  very  few  have  put  in  place  an  end- 
to-end  strategic  approach  that  incorporates  security  throughout 
the  software  development  lifecycle.”  The  supply  chain  implication 
is  that  reviewing  a  vendor’s  secure  development  practices  is  an 
important  step  in  managing  supply  chain  risks. 

This  raises  several  important  questions,  such  as:  what  a  secure 
development  process  should  include,  how  an  organization  should 
manage  that  process,  and  how  a  vendor’s  process  should  be  eval¬ 
uated?  An  obvious  start  is  to  ensure  that  a  vendor  has  a  secure 
development  process,  that  it  incorporates  techniques  that  address 
real-world  security  threats,  and  that  the  vendor’s  organization 
is  clearly  committed  to  supporting  that  process.  But  what  is  the 
right  approach  to  creating  such  a  process?  And  what  else  should 
be  considered?  In  November  201 1  the  International  Standards 
Organization  published  part  1  of  ISO  27034,  an  internationally 
recognized  application  security  standard  that  may  help  simplify 
the  answers  to  those  questions.  Currently  Part  1 :  Overview  and 
concepts  is  published  and  latter  parts  are  still  in  development. 

ISO  27034-1  provides  frameworks  and  a  process  that  can 
help  inform  a  vendor’s  approach  to  build  and  operate  a  com¬ 
prehensive  application  security  program.  The  standard  can 
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also  help  an  organization  validate  and  identify  gaps  within  their 
current  application  security  program.  Additionally,  the  standard 
can  help  an  organization  implement  aspects  of  ISO  27001  via 
the  systematic  approach  to  risk  management  shared  by  the 
standards.  ISO  27034-1  includes  an  annex  that  demonstrates 
how  an  existing  development  process  based  on  the  Microsoft 
Security  Development  Lifecycle  aligns  to  ISO  27034.  This  may 
help  simplify  an  organization’s  efforts  to  implement  the  standard. 

An  organization  that  has  reviewed  and  is  considering  adoption 
of  ISO  27034-1  is  likely  to  be  taking  a  strategic  approach  to  soft¬ 
ware  security  and  be  applying  relevant  application  security  con¬ 
trols  through  all  phases  of  their  software  development  lifecycle. 
Consequently,  ISO  27034  may  be  a  helpful  tool  to  simplify  the 
process  of  managing  supply  chain  risks  by  providing  a  standards 
based  approach  for  understanding  if  vendors  in  your  supply  chain 
are  taking  a  strategic  and  holistic  approach  to  software  security. 

Conclusion 

Modern  supply  chains  have  introduced  greater  risks  to  organi¬ 
zations.  Globalization  and  the  proliferation  of  technology  around 
the  globe  have  presented  new  significant  threats  to  national  se¬ 
curity,  economic  security  and  protection  of  intellectual  property 
(investment).  The  combination  of  international  standards  efforts 
described  in  this  paper  will  help  to  provide  a  solid  foundation  for 
organizations  to  integrate  an  organizationally  driven,  risk  based 
implementation  of  ICT  SCRM  practices. 
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A  Look  at  Risks  vs.  Rewards 


Wayne  Jackson,  Sonatype 

Abstract.  There  is  a  dynamic  shift  occurring  in  the  software  development  land¬ 
scape.  No  longer  are  applications  written,  today  most  are  assembled  using  open 
source  components.  The  growing  reliance  on  externally  sourced,  open-source 
components  as  core  building  blocks  for  modern  application  development,  coupled 
with  the  complexity  of  the  ecosystem,  has  ushered  in  new  risks  for  the  software 
supply  chain. 

This  article  will  explore  the  licensing,  security,  and  quality  risks  associated 
with  component-based  development  and  its  direct  impact  on  the  integrity  of  the 
software  supply  chain. 

Introduction 

For  most  of  its  history,  software  has  been  written-appli¬ 
cations  consisted  primarily  of  custom  developed  code  and 
internally  developed  components  with  only  a  small  fraction  of 
code  sourced  from  outside  the  organization.  Development  ef¬ 
forts  followed  a  “waterfall”  methodology  and  projects  spanned 
months  or  even  years.  The  widespread  use  of  cloud-based  infra¬ 
structures  and  the  rise  of  open-source  technologies  during  the 
past  decade  have  heavily  influenced  the  software  development 
landscape  with  startups  and  established  organizations  demand¬ 
ing  increased  flexibility  and  improved  time  to  value  in  the  way 
software  is  developed  and  delivered.  As  a  result,  modern  soft¬ 
ware  development  and  the  resulting  software  supply  chain  have 
become  increasingly  component-based,  where  applications  are 
assembled  from  existing  components  rather  than  written  from 
scratch.  Enterprise  applications  today  are  typically  built  using 
75%  to  80%  open  source  components  [1],  with  custom  code 
comprising  the  rest.  So,  what  does  today’s  software  develop¬ 
ment  landscape  look  like  and  what  are  the  risks  to  the  software 
supply  chain? 


Software  Development  Once  Was... 

Software  Development  Now  Is... 

Waterfall  Methodology 

Agile  Development 

Code- Based 

Component-Based 

Developed 

Assembled 

Independent 

Collaborative 

Proprietary 

Open  Source 

Table  1: 


First,  modern  software  development  is  increasingly  compo¬ 
nent-based.  The  vast  majority  of  these  components  are  sourced 
from  outside  the  organization. 


Second,  open  source  has  become  an  integral  part  of  modern 
applications.  In  most  cases,  externally  sourced  components  are 
open  source.  Modern  applications  often  rely  on  hundreds  of 
open  source  components  and  frameworks. 

Third,  development  organizations  have  embraced  agile  soft¬ 
ware  development  processes.  The  modern  development  process 
is  rapid,  continuous,  and  collaborative. 

While  development  teams  have  embraced  agile  software  devel¬ 
opment  processes,  the  shifting  software  development  landscape 
has  also  introduced  new  risks  and  requirements  in  the  software 
supply  chain.  Applications  can  be  composed  of  hundreds  of  com¬ 
ponents  sourced  from  a  myriad  of  open-source  projects  and  these 
components  can  in  turn,  depend  on  other  components,  known 
as  transitive  dependencies.  This  creates  an  enormously  complex 
software  supply  chain,  where  a  single  application  may  contain  com¬ 
ponents  originally  published  by  dozens  of  individual  projects. 

To  see  just  how  far  reaching  externally  sourced  open  source 
components  are  in  the  software  supply  chain,  look  no  further  than 
the  Central  Repository,  the  industry’s  primary  source  for  open 
source  components.  The  Central  Repository  receives  7.5  billion 
requests  annually  and  is  used  by  more  than  60,000  organizations 
worldwide.  Large  organizations  that  rely  on  custom  software  for 
competitive  advantage  are  the  biggest  consumers  of  the  400,000 
components  in  the  repository,  but  demand  comes  from  every 
industry  and  geography. 

Whether  provided  by  commercial  vendors  or  open  source 
initiatives,  components  can  introduce  significant  management, 
security  and  licensing  challenges.  Think  of  today’s  software 
as  being  assembled  rapidly  with  a  very  complex  supply  chain 
like  that  of  a  car  manufacturer.  Like  a  car,  the  final  product  (an 
application)  may  contain  hundreds  or  thousands  of  externally 
sourced  components  from  dozens  or  hundreds  of  original  sup¬ 
pliers.  Each  of  these  components  has  its  own  lifecycle,  its  own 
bug  fixes  and  feature  enhancements,  and  its  own  potential  risks. 

Like  a  car,  a  single  flawed  component  could  cause  significant 
problems  for  the  user.  In  the  worst  case,  these  problems  could 
lead  to  security  breaches,  data  leaks,  stability,  and  performance 
issues,  or  legal  actions  related  to  intellectual  property. 

An  easy  example  of  a  potential  problem  is  in  the  area  of 
security.  Recent  analysis  by  Aspect  Security,  using  data  from  the 
Central  Repository,  uncovered  widespread  security  vulnerabili¬ 
ties  among  the  most  commonly  used  open  source  components. 

Often  risks  are  caused  by  flawed  components  nested  deep  in 
an  application’s  dependency  tree  where  flaws  are  not  easily  ap¬ 
parent.  Dependencies  may  allow  flawed  components  to  quickly 
infiltrate  and  undermine  the  software  supply  chain. 

Users  of  the  Central  Repository  regularly  consume  outdated, 
flawed  or  insecure  components  even  years  after  newer  fixed 
versions  are  available.  An  example  of  this  can  be  seen  when  the 
United  States  Computer  Emergency  Readiness  Team  and  NIST 
issued  a  warning  in  March  2009  that  the  Legion  of  the  Bouncy 
Castle  Java  Cryptography  API  artifact  was  extremely  vulnerable 
to  remote  attacks.  Almost  two  years  later  in  January  2011,  more 
than  1 ,500  organizations  downloaded  the  vulnerable  version  of 
Bouncy  Castle  from  the  Central  Repository  in  a  single  month  [3]. 
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Total  Downloads  with  Known  Vulnerabilities  (Logarithmic) 
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Deep  transitive 
dependency  with 
high  risk  vulnerability 


Figure  2:  From  reference  [1] 


Components  you 
integrated  into 
your  application 


Hidden  dependency 
licensed  under  GPLv3 


Figure  3:  From  reference  [2] 
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Open  source  projects  innovate  rapidly  and  release  frequently. 
However  there  is  no  update  notification  infrastructure  for 
open  source  components.  Therefore  there  is  no  easy  way  for 
component  consumers  to  know  when  a  new  version  has  been 
released,  much  less  which  defects  have  been  fixed. 

Because  open  source  usage  generally  occurs  under  the 
corporate  radar,  it  is  not  uncommon  for  organizations  to  be 
unaware  of  which  components  are  being  used  in  their  software 
supply  chain  or  within  key  production  applications. 

Agile  software  development,  incremental  deployment  and 
continuous  integration  have  all  resulted  in  many  more  builds 
over  the  life  of  a  software  project.  Measurements  of  software 
quality  and  risks  must  be  conducted  in-band  during  the  develop¬ 
ment  and  build  process.  Development  teams  are  increasingly 
geographically  dispersed  and  often  include  external  contractors. 
Keeping  disparate  teams  in  sync  and  enforcing  standards  is 
increasingly  important  to  minimize  waste  and  risk. 

To  firmly  establish  both  control  and  visibility  across  today’s 
complex  and  agile  software  supply  chain,  organizations  should 
take  the  following  steps  toward  Component  Lifecycle  Manage¬ 
ment  (CLM)-or  the  practice  of  proactively  managing  the  use  of 
components  throughout  the  supply  chain. 

Step  1:  Inventory  -  Gather  information  about  your  current 
component  usage: 

•  Track  component  downloads  and  usage  to  understand 
consumption. 

•  Inventory  internal  component  repositories  to  determine 
what  is  being  distributed  to  development  teams. 

•  Understand  the  software  supply  chain  to  determine 
which  components  and  dependencies  are  being 
introduced  to  the  organization. 

Step  2:  Analyze  -  Understand  vulnerabilities  in 
applications  and  repositories: 

•  Analyze  key  applications  to  uncover  known 
security  vulnerabilities. 

•  Analyze  internal  component  repositories  to  discover 
vulnerable  components. 


When  a  component  is  updated,  how  do  you  know? 

74% 


By  searching  the  web 
Keeping  up  with  project  sites 


From  colleagues 
Word  of  mouth 
No  good  way  to  find  out 


2012  Sonatype  survey  of  2,550  developers,  architects,  and  managers 


Figure  4:  From  reference  [4] 


Does  your  organization  maintain  an  inventory  of  open 
source  components  used  in  production  applications? 


48%  No 

32%  Yes,  for  all  components  including  dependencies 
20%  Yes,  for  all  components  but  NOT  their  dependencies 


2012  Sonatype  survey  of  2,550  developers,  architects,  and  managers 


Figure  5:  From  reference  [4] 


Step  3:  Control  -  Establish  controls  throughout  the 
development  lifecycle: 

•  Establish  policies  regarding  security,  the  use  of  viral 
licenses  and  the  out-of-date  or  out-of-version  components. 

•  Eliminate  or  blacklist  known  vulnerable  components  in 
internal  repositories. 

•  Establish  mechanisms  to  prevent  known  flawed 
components  from  entering  the  organization. 

•  Implement  controls  in  build  and  continuous  integration 
systems  to  prevent  inclusion  of  flawed  components  in 
software  builds. 


Step  4:  Monitor  -  Maintain  awareness  of  component  updates: 

•  Maintain  an  inventory  of  all  components  and  dependencies 
used  in  production  applications. 

•  Continuously  monitor  application  bill-of-materials  for 
updates  and  newly  discovered  vulnerabilities. 

Properly  managing  the  use  of  open  source  components 
throughout  the  software  development  lifecycle  will  enable  or¬ 
ganizations  to  ensure  the  integrity  of  the  software  supply  chain 
and  focus  on  the  cost  savings  and  wealth  of  innovation  open 
source  software  can  bring.  ^ 
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Advancing  SCRM 
with  Standardized 
Inspection  Technology 

Roger  Stewart,  Stewart-Priven  Group 

Abstract.  Technology  exists  today  that  can  make  a  huge  improvement  mini¬ 
mizing  risk  along  the  supply  chains  and  improve  delivery  of  secure,  high-quality 
products,  on  time  and  within  budget.  And  no  changes  to  standards,  legislation, 
or  acquisition  models  are  needed.  Accepting  this  approach  to  Supply  Chain  Risk 
Management  (SCRM)  by  industry  and  government  means  adopting  policies  to: 

1 .  Impose  contract  stipulations  on  the  prime  contractor,  such 
as  common  tools  and  process  use,  that  must  also  apply  to  all 
vendors  along  their  supply  chain,  and  their  vendor’s  supply  chains, 

2.  Require  a  common,  standardized  platform  of:  tools, 
process  and  training  along  the  supply  chains  for  consistently 
performing  ongoing  product  risk  assessments  through  defect 
identification  and  removal  on  pre-code  product  definition 
artifacts  (e.g.,  contracts,  requirements,  architecture,  design,  in¬ 
terfaces),  where  past  studies  report  more  than  70%  of  product 
defects  historically  originate  [1]. 

3.  Require  results  of  each  product  risk  assessment  be  made 
available  to  both  the  prime  contractor  and  the  government 
program  manager  in  the  form  of  an  automated,  tool-generated 
report  with  common  format  and  content. 

4.  Include  contract  leverage  for  the  government  program 
office  based  upon  their  ongoing  evaluations  of  the  resulting 
product  risk  visibility. 

5.  Use  a  tool-enabled,  standard-compliant  inspection  pro¬ 
cess  for  defect  identification  and  removal  in  Product  Definition 
artifacts  along  the  supply  chain  and  for  achieving  the  ongoing 
product  risk  assessments  and  reports. 


Introduction 


Figure  1.  Potential  Software  Supply  Chain  Paths 


The  supply  chains  in  today’s  software  acquisition  world 
consist  of  a  wide  variety  of  suppliers  spread  across  the  world 
(Figure  1).  Each  of  these  suppliers  may  have  their  own  stan¬ 
dards  for  development  and  quality  assurance.  Therefore,  the 
responsibility  for  software  assurance  must  be  shared  not  only  by 
software  suppliers  in  the  supply  chain  but  also  by  the  acquirer  in 
the  supply  chain  who  purchase  the  software  [2]. 

A  key  to  advancing  SCRM  is  through  standardized  inspec¬ 
tions  using  tool-enabling  technology  for  correction  of  past 
inspection  perceptions  and  shortfalls. 

The  first  4  of  the  5  proposed  policies  (see  Abstract)  are 
contract  related  actions  that  are  dependent  upon  the  viability 
of  standardized  inspections  to  provide  sustained  results  in 
removing  pre-code  defects  and  reporting  on  the  associated 
product  risk  assessments  inspections  can  provide.  This  article 
will  explore  the  viability  of  incorporating  standardized  inspec¬ 
tions  along  the  supply  chain  (Figure  2)  for  visibility  into  pre-code 
product  definition  activities. 

Note:  Federal  Acquisition  Regulation  Part  46.202  on  qual¬ 
ity  assurance  currently  addresses  inspection  on  government 
contracts  [3]. 


Figure  2.  Standardized  Inspection  of  Product  Definition 
Artifacts  along  the  Supply  Chain 

Inspections  are  a  preventative  systematic  analysis  of  a 
work-product  or  portion  thereof,  by  a  team  of  three  to  five  peer 
stakeholders  to  remove  defects  at  or  closest  to  their  points  of 
introduction.  Inspections  provide  the  best  value  when  applied  to 
up-front,  pre-code  product  definition  artifacts  where  more  than 
70%  of  product  defects  are  historically  introduced  [1],  and  on 
change  instruments  (e.g.,  test  fixes,  change  requests)  which  are 
defect-prone  due  to  their  late  application  to  a  product. 

Using  a  tool-enabled,  standard-compliant1  inspection  pro¬ 
cess  implementation2  is  a  key  to  removing  product  definition 
defects  and  eliminating  past  dramatic  variances  in  inspection 
results  and  benefits. 
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For  example,  recent  training  in  tool-enhanced,  standard 
compliant  inspections  on  a  DoD  agency  project  resulted  in 
the  six  participating  teams  collectively  finding  236  non-trivial 
defects  in  the  290  lines  of  actual  requirement  text  their  project 
had  previously  generated;  a  defect  density  of  81 4  defects  per 
1,000  lines  of  requirements.  Afterward  on  this  project’s  first 
post-training  inspection  using  the  tools  and  techniques  they  had 
learned  in  class,  the  trained  inspectors  discovered  1 63  non¬ 
trivial  defects  in  another  1 80  lines  of  requirement  text;  a  defect 
density  of  906. 

Comparing  fixing  these  defects  at  their  points  of  introduction 
using  a  compliant  inspection  process  (as  depicted  above  and 
in  Figure  3),  versus  randomly  discovering  and  fixing  problems 
throughout  development  (e.g.,  requirement  reviews,  design,  code, 
test)  and  operations  without  compliant  inspections,  revealed 
potential  estimated  net  project  savings  of  more  than  20,000 
hours  from  the  training  results  and  an  additional  1 0,000  or  more 
hours  from  their  first  post-class  inspection!  When  further  consid¬ 
ering  the  resulting  quality,  security  and  schedule  issues  that  can 
spawn  from  defects  not  found  early,  the  benefits  of  uniformly 
applying  compliant  inspections  throughout  the  supply  chains, 
shown  by  the  circle  indicators  in  Figure  2,  to  pre-code  activities 
can  be  better  appreciated. 

Standardizing  Inspections 

Tragically,  effective  inspections  are  no  longer  used  by  most 
organizations,  despite  the  perform  peer  reviews  specific  goal 
and  practices  of  CM  Ml®  Maturity  Level  3.  Reasons  why  this  pre¬ 
vious  best  practice  [4]  is  no  longer  in  favor  include  the  following: 

1:  Inspection  Pitfalls  -  the  10  most  important  reasons 
were  captured  in  Stewart-Priven  Group’s  article  [5]  published 
in  January  2008  explaining  why  organizations  experience  poor 
inspection  value  and  inability  to  sustain  early  defect  removal 
results  due  to  unknowingly  encountering  any  of  the  1 0  inspec¬ 
tion  Pitfalls  described: 

1 .  Immature  development  infrastructure 

2.  Management  responsibilities  not  understood 

3.  No  inspection  planning  tools 

4.  Insufficient  time  allotted 

5.  No  inspector  execution  tools  for  consistency- 
rigor-completeness,  and  no  tools/reports  for 
management  monitoring 

6.  Limited  result  tracking  &  analysis 

7.  No  post-training  follow  up 

8.  Lack  of  project-wide  facilitation 

9.  Slow  implementation 

1 0.  No  inspection  process  capture 

Adding  to  these  pitfalls  are  a  lack  of  education  of  software 
engineers,  and  the  generic  non-specific  meaning  that  the  terms 
peer-review  and  inspection  have  evolved  to. 

2:  Code  Inspection  vs.  Product  Definition  Inspection 

-  Organizations  then  and  now  tend  to  believe  inspection  value 
applies  mainly  to  code,  which  is  not  true.  Code  analyzer  compa¬ 
nies  introduced  high-tech  static  analysis  capabilities  in  the  early 


TOOL-ENABLED,  STANDARD  COMPLIANT  INSPECTION  RESULTS 


DOD  AGENCY  PROJECT  -  EXAMPLE 

Training  Class 
Inspections 

Post- Class 
1st  Inspection 

1.  Requirement  Lines  Inspected 

290 

180 

2.  Non-Trivial*  Defects  Found 

236 

163 

3.  Defect*  Density  (per  1,000  lines) 

814 

906 

4.  Hours  to  Find- Fix  Defects*  by  Inspection 

343 

225 

5.  Hours  Est.  to  Find-Fix  Defects*  without  Inspection 

21 ,289 

10,898 

6.  Projected  Hours  Saved  by  Early  Defect*  Removal 

20,946 

10,673 

7.  ROI  (Return  on  Investment) 

61.1 

47.4 

*  non-trivial  defect:  incorrect,  missing,  unclear  or  ambiguous  statement 


Figure  3.  Example  of  Compliant  Inspections  applied  to 
Product  Definition  Material 


2000s  with  marketing  that  downplayed  inspection  value  and 
Fagan  inspections  in  particular,  attempting  to  convince  industry 
and  government  to  employ  their  automated  defect  removal  tech¬ 
nologies.  Code  analyzers,  for  the  most  part,  are  not  succeeding 
in  achieving  high-quality  software  systems.  General  William 
Shelton’s  opening  remarks  at  the  April  2009  DoD  Systems  & 

Software  Technology  Conference  focused  on  the  deteriorating 
state  of  software-driven  systems.  More  recently,  this  was  a  focus 
of  J.M.  Gilligan’s  article  in  the  February  2012  issue  of  Software 
Technology  titled  “A  Roadmap  for  Reforming  the  DoD’s  Acquisi¬ 
tion  of  Information  Technology[6].”  How  could  code  analyzers 
alone  remedy  a  situation  where  the  majority  of  defects  are 
introduced  pre-code,  during  product  definition  activity? 

3:  Inspection  Cost  vs.  Project  Savings  -  Organizations 
tend  to  believe  inspections  are  a  cost  rather  than  a  savings/ 
investment  despite  huge  quantities  of  data  to  the  contrary.  The 
Stewart-Priven  Group  introduced  savings  estimation  capabil¬ 
ity  for  software-driven  projects  to  easily  demonstrate  their 
expected  net  project  savings  from  inspection  across  multiple 
disciplines  before  actually  committing  to  inspection.  Inspec¬ 
tion  planning  tools  can  guide  projects  in  using  their  own  past 
development  history  (or  estimates)  to  perform  what-if  analysis  to 
pre-determine  their  projected  net  savings  from  using  inspection. 

More  visibility  is  needed  into  the  merits  of  inspection  planning 
and  saving  estimation  tools. 

4:  Manual  Inspection  vs.  Tool-Enabled  Inspection 

-  Computerized  inspection  tools  bring  added  value  to  inspec¬ 
tions  by  enabling  adherence  to  the  inspection  standard  in 
section  six  of  IEEE  Std  1028™-2008,  ensuring  consistency, 
completeness  and  rigor.  Tool-enabled  inspections  can  also 
provide  interim  and  final  one-page  automated  management  re¬ 
ports  of  inspection  process  deviations,  find/fix  defect  progress, 

ROI  for  individual  inspections,  accumulated  labor  and  dollar 
savings,  and  rolled-up  project  inspection  results.  Unfortunately 
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The  overriding  value  tools  provide  is  in 
achieving  compliance  to  the  standard 
for  adherence  to  the  performance 
criteria  boundaries  reguired  for  effective 
inspections,  and  their  ongoing  product 
risk  assessments. 

misleading  material  clouds  the  perception  of  inspections  or 
can  imply  the  inspection  process  can  be  tailored  by  organiza¬ 
tions;  where  resulting  consequences  would  actually  weaken 
or  undermine  the  performance  criteria  upon  which  inspections 
depend  for  success.  The  establishment  of  performance  criteria 
that  defined  and  enabled  effective  inspections  was  the  output 
of  the  five-year  experiment  in  the  1 970s,  envisioned  by  Lew 
Priven  who  hired  Michael  Fagan  to  lead  the  effort  to  improve 
IBM  software  product  quality  while  reducing  cost  and  sched¬ 
ule.  The  experiment’s  result  became  known  as  “inspection”  or 
“software  inspection,”  used  initially  by  IBM  internally,  and  now 
the  foundation  of  the  2008  Inspection  Standard. 

5:  Streamlined  Inspections  vs.  Compliant  Inspections  - 

Using  inspections  for  effective  early  defect  removal  and  ongoing 
product  risk  assessment  must  employ  inspection  specific  tools 
to  ensure  any  non-compliance  with  the  inspection  standard  is 
identified  during  an  inspection.  Without  tool-enabled  inspections, 
deviating  from  the  inspection  standard/process  is  inevitable  and 
organizations  will  fall  into  the  same  pitfalls  that  contribute  to  the 
tarnished  reputation  of  traditional  manual  inspections.  Organiza¬ 
tions  that  streamline,  tailor,  or  re-do  inspection  material  to  fit  their 
needs,  or  for  their  own  use  under  the  guise  of  public  domain,  do 
not  understand  the  limits  of  inspection  performance  criteria,  or  the 
importance  of  rigor,  repeatability  and  consistency  that  standard- 
compliant  inspection  tools  provide  for  ongoing  early  removal  of 
defects  in  product  definition  artifacts  that  code  analyzers  are  typi¬ 
cally  unsuccessful  in  removing.  Inspections  are  required  for  early 
defect  removal  in  product  definition  artifacts,  as  recent  history 
seems  to  demonstrate  [7];  plus,  there  is  no  current  alternative  to 
inspections  for  ongoing  product  risk  assessment!  CM  Ml  for  pro¬ 
cess  adherence  is  necessary  but  history  and  DoD  studies  have 
shown  it  not  to  be  sufficient  for  attaining  consistent  high-quality, 
on-time,  and  within  budget  deliveries  [2].  Without  using  standard- 
compliant  inspection  execution  tools  in  real-time  throughout  the 
seven-step  inspection  process,  then  effective  early  defect  removal 
from  product  definition  artifacts  and  change  instruments  cannot 
be  sustained  leading  to  project  efforts  becoming  prohibitively 
expensive  or  failing. 

6:  Human  Shortfalls:  These  include  resistance  to  change, 
preserving  the  status  quo,  protecting  personal  income  and 
influence,  and  egos  that  make  peers  resist  detecting  errors 
in  their  work.  All  these  contribute  to  late  and  costly,  problem- 
ridden  capabilities. 


The  Way  Forward 

Inspection  process  adherence  using  standard-compliant, 
computerized  tools  must  be  the  prime  focus  of  inspection  train¬ 
ing  and  repeatedly  reinforced  to  consistently  reap  the  benefits 
of  pre-code  early  defect  removal,  as  the  results  in  Figure  3  dem¬ 
onstrate.  There  are  other  advantages  of  an  integrated  inspection 
tool  set  to  supply  chain  risk  management  such  as  consistent 
and  complete  data  collection,  result  tracking,  and  accumulated 
savings.  However  the  overriding  value  tools  provide  is  in  achiev¬ 
ing  compliance  to  the  standard  for  adherence  to  the  perfor¬ 
mance  criteria  boundaries  required  for  effective  inspections,  and 
their  ongoing  product  risk  assessments.  Product  risk  visibility 
derived  from  each  compliant  inspection  across  the  supply  chain, 
and  uniformly  formatted  by  a  contract  specified  inspection  tool 
can  provide  the  prime  contractor  and  government  program  of¬ 
fice  a  powerful  vehicle  to  manage  product  risk. 

Awareness  of  the  vendor  offerings  for  standard-compliant, 
tool-enhanced  inspection  capabilities  that  eliminate  past  inspec¬ 
tion  shortfalls  and  misleading  perceptions;  and  awareness  that 
inspection  must  be  used  during  product  definition  activity  where 
most  defects  are  introduced,  and  on  change  instruments  due 
to  their  defect-prone  nature.  As  for  code,  the  code  analyzers 
continue  to  be  necessary  but  are  not  sufficient.  This  message 
needs  to  stress  that  tool-enabled,  standard-compliant  inspec¬ 
tions  are  the  most  effective  alternative  before  coding.  J.  M. 
Gilligan’s  February  2012  article  [6],  with  its  several  references 
to  recent  government  reports,  highlights  the  inadequate  state  of 
government  software-driven  systems,  and  that  a  path  forward  is 
available  with  current  technology. 

Summary/Conclusion 

Consistently  attaining  on-time,  high-quality,  cost-effective,  and 
secure  software  requires  agile  techniques,  process  adherence 
discipline,  sophisticated  code-analyzers,  and  rethinking  supply- 
chain  risk  management.  These  are  all  being  done  today,  but 
they  are  not  enough  to  end  quality,  schedule,  and  cost  struggles! 
Ongoing  product  risk  assessments  also  need  to  be  the  norm, 
coupled  with  effective  early  defect  removal  from  pre-code 
product  definition  artifacts.  Tool-enhanced,  standard-compliant 
inspection  provides  both. 

Deploying  standardized  inspections  for  product  definition  arti¬ 
facts  along  the  supply  chain  shown  in  Figure  2  would  go  a  long 
way  to  mitigating  current  supply  chain  risk  and  improve  product 
quality,  security,  schedule  and  cost.^ 

Disclaimer: 

CM  Ml®  is  registered  in  the  U.S.  Patent  and  Trademark  Office 
by  Carnegie  Mellon  University. 


1.  Standard:  document,  established  by  consensus  and  approved  by  a  recognized  body, 
that  provides,  for  common  and  repeated  use,  rules,  guidelines  or  characteristics  for 
activities  or  their  results,  aimed  at  the  achievement  of  the  optimum  degree  of  order 
in  a  given  context 

2.  Process  (formal):  set  of  interrelated  or  interacting  activities  which  transforms 
inputs  into  outputs;  and  in  the  context  of  this  article,  implementing  a  Standard 
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Building  a  Body  of 
Knowledge  for  ICT 
Supply  Chain  Risk 
Management 

Dan  Shoemakeri  Ph.D.,  University  of  Detroit  Mercy 
Nancy  R.  Mead,  Ph.D.,  SEI 

Abstract.  This  paper  proposes  a  set  of  Supply  Chain  Risk  Management  (SCRM) 
activities  and  practices  for  Information  and  Communication  Technologies  (ICT). 

This  set  can  be  used  as  a  starting  point  to  create  a  body  of  knowledge  in  SCRM  to 
ensure  the  integrity  of  ICT  products. 

Introduction 

ICT  is  a  vital  part  of  our  culture.  In  fact,  many  would  argue  that 
computers  and  their  associated  communications  technologies 
have  created  that  culture.  Because  we  depend  so  much  on  our 
ICT  products,  it  is  critically  important  to  be  able  to  trust  their 
integrity.  Yet,  commonly  used  ICT  development  and  sustainment 
practices  still  permit  dangerous  defects  that  allow  attackers  to 
compromise  millions  of  computers  every  year  [1  ].  The  increas¬ 
ing  trend  toward  building  systems  out  of  purchased  parts  just 
enhances  the  importance  of  getting  the  acquisition  of  ICT 
components  right  [2]. 

Early  in  this  decade,  NIST  estimated  that  exploitation  of  ICT 
defects  costs  the  U.S.  economy  an  average  of  $60  billion  an¬ 
nually,  and  there  is  no  reason  to  think  that  those  numbers  have 
improved  since  then  [3].  But  the  real  concern  is  not  cybercrime; 
it  is  that  the  exploitation  of  a  point  of  failure  in  an  infrastructure 
component  like  power  or  communication  could  have  severe  con¬ 
sequences.  Therefore,  it  is  not  surprising  that  the  U.S.  govern¬ 
ment  is  addressing  the  problem  of  product  integrity  through  a 
comprehensive  program  to  get  better  SCRM  practices  into  the 
workforce.  This  program  includes  education,  training,  and  aware¬ 
ness  initiatives,  which  are  the  traditional  means  of  leveraging  the 
required  change  in  workforce  behavior.  However,  when  it  comes 
to  SCRM,  although  much  progress  has  been  made  [4,  5]  there 
is  still  no  single  reference  to  define  what  should  be  taught  [6,  7]. 

An  authoritative  Body  of  Knowledge  (BOK)  of  best  practices 
for  SCRM  is  an  attractive  idea.  Such  a  BOK  would  portray  the 
SCRM  process  as  a  complete  set  of  topics.  The  BOK  would 
integrate  the  knowledge  needed  for  effective  management  of 
supply  chain  risk  into  a  framework  that  contains  all  of  the  advice 
necessary  to  ensure  ICT  product  integrity.  The  aim  would  be 
to  characterize  and  relate  all  the  detailed  knowledge  elements 
needed  to  develop  precise  workforce  learning  requirements,  as 
well  as  the  methods  to  deliver  that  learning.  In  addition,  a  com¬ 
monly  accepted  BOK  could  be  used  as  leverage  to  develop  new 
education  and  training  curricula  as  the  field  evolves  [6,  7]. 


Several  conventional  disciplines  could  be  part  of  a  discipline 
of  ICT  SCRM,  such  as  hardware  and  software  engineering, 
systems  engineering,  information  systems  security  engineer¬ 
ing,  safety,  security,  reliability,  testing,  information  assurance, 
and  project  management  [6].  In  addition,  it  would  be  possible  to 
consider  academic  areas  such  as  intelligence  analysis  and  law 
as  potential  parts  of  the  discipline.  Because  these  are  highly 
disparate  fields,  it  is  important  to  create  a  detailed  model  of  the 
relationship  between  all  of  the  logical  components  in  order  to 
judge  whether  the  right  content  is  being  provided  in  each  edu¬ 
cation  and  training  setting. 

ICT  SCRM  in  Common  Standards 

ICT  products  are  developed  through  a  global  supply 
chain.  Supply  chains  are  no  different  from  any  other  organiza¬ 
tional  function  in  that  they  are  intended  to  accomplish  a  specific 
purpose.  The  purpose  of  all  supply  chains  is  to  provide  a  product 
or  service  through  coordinated  work  that  involves  several 
organizations.  The  concerns  about  supply  chains  fall  into  five 
categories.  Each  category  has  slightly  different  implications  for 
product  integrity:  “Installation  of  malicious  logic  on  hardware  or 
software,  installation  of  counterfeit  hardware  or  software,  failure 
or  disruption  in  the  production  or  distribution  of  a  critical  product 
or  service,  reliance  upon  a  malicious  or  unqualified  service  pro¬ 
vider  for  the  performance  of  a  technical  service  and  installation 
of  unintentional  vulnerabilities  on  software  or  hardware  [2].” 

Proper  SCRM  mitigates  these  concerns  by  providing  a 
consistent,  disciplined  environment  for  developing  the  product, 
assessing  what  could  go  wrong  in  the  process  (i.e.,  assessing 
risks),  determining  which  risks  to  address  (i.e.,  setting  mitigation 
priorities),  implementing  actions  to  address  high-priority  risks 
and  bringing  those  risks  within  tolerance  [8].  Typically,  supply 
chains  are  hierarchical,  with  the  primary  supplier  forming  the 
root  of  a  number  of  levels  of  parent-child  relationships.  From  an 
assurance  standpoint,  what  this  implies  is  that  every  individual 
product  of  each  individual  node  in  that  hierarchy  has  to  be  cor¬ 
rect  as  well  as  correctly  integrated  with  all  other  components  up 
and  down  the  production  ladder.  Because  the  product  develop¬ 
ment  process  is  distributed  across  a  supply  chain,  maintaining 
the  integrity  of  the  products  that  are  moving  within  that  process 
is  the  critical  concern. 

The  weak  link  analogy  is  obvious  here,  so,  whether  the 
product  is  a  common  household  item  or  sophisticated  military 
hardware,  the  activities  within  that  product’s  supply  chain  have 
to  be  precisely  coordinated  and  carefully  controlled.  Authorita¬ 
tive  control  processes  already  exist,  which  specifically  address 
the  existing  coordination  and  control  concerns.  These  processes 
are  embodied  in  the  activities  and  tasks  of  two  international 
“umbrella”  standards.  The  recommendations  of  these  standards 
have  been  validated  worldwide.  So  besides  providing  authorita¬ 
tive  real-world  advice  about  how  to  manage  supply  chain  risk, 
the  detailed  activities  and  tasks  that  are  specified  in  those 
standards  also  provide  a  coherent  and  detailed  logic  for  a  BOK 
of  SCRM  best  practices. 
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Building  a  Framework  for  the  BOK  of  SCRM 
Education  From  Two  International  Standards 

At  present,  there  is  no  complete  classification  structure  for 
the  BOK  for  ICT  SCRM.  Thus  our  aim  was  to  derive  a  concep¬ 
tual  model  for  the  discipline  based  on  existing  standards.  A 
standard  conceptual  model  is  essential  in  order  to  ensure  proper 
associations  between  the  many  disparate  knowledge,  skills,  and 
abilities  required  to  produce,  maintain,  and  acquire  trustwor¬ 
thy  ICT  products.  The  DHS  uses  the  term  Enterprise  Security 
Framework  (ESF)  to  describe  the  specific  set  of  actions  needed 
to  ensure  the  reliability  of  purchased  products  [9].  The  aim  of 
an  ESF  is  to  factor  everybody’s  actions  for  achieving  secure 
products  into  a  “who,  what,  when”  structure  of  defined  activities 
and  interrelationships.  To  create  this  structure,  DHS  suggests 
that  the  ESF  must  include  responsibilities  beyond  the  typical 
system  and  software  security  activities  seen  in  most  organiza¬ 
tions.  These  responsibilities  can  be  implemented  by  blend¬ 
ing  top-level  risk  management  activities  contained  in  the  ISO 
1 6085  Lifecycle  Risk  Management  standard  with  the  activity 
and  task  recommendations  of  the  Agreement  processes  of  the 
ISO  12207-2008  standard. 

The  activities  embodied  in  the  1 2207  Agreement  process 
convey  the  steps  that  an  organization  should  take  to,  “manage 
the  procurement  of  a  system,  software,  or  service  product.”  The 
agreement  processes  are  particularly  relevant  to  those  inter¬ 
ested  in  defining  the  discipline  of  SCRM  in  that  they  provide  a 
structured  and  rigorous  set  of  activities  and  tasks  to  carry  out 
the  effort.  The  1 2207-2008  activities  specified  for  acquisition 
convey  the  practices  that  have  to  be  performed  when  an  orga¬ 
nization  procures  a  software  system  or  service,  while  the  supply 
process  (6.1.2)  delineates  the  obligations  of  the  supplier.  Using 
the  1 2207-2008  standard,  it  is  possible  to  form  a  detailed 
definition  of  the  standard  customer  supplier  activities  involved 
in  ICT  procurement.  However,  that  definition  does  not  take  risk 
management  into  consideration. 

The  purpose  of  ISO  16085  System  and  Software  Supply 
Chain  Risk  Management  is  to  identify  potential  managerial 
and  technical  actions  to  reduce  or  eliminate  the  probability  and 
impact  of  risk  [10].  The  standard  may  be  used  for  managing  risk 
at  the  organizational,  enterprise,  or  project  level  in  any  domain 
or  lifecycle  stage  [10].  The  aim  is  to  support  the  perspectives  of 
managers,  suppliers,  acquirers,  developers,  participants,  and  oth¬ 
er  stakeholders  and  provide  them  with  a  single  set  of  process 
requirements  suitable  for  the  management  of  a  broad  variety  of 
risks  in  the  supply  chain  [1 0].  The  standard  prescribes  a  con¬ 
tinuous  process  for  risk  management  and  is  useful  for  manag¬ 
ing  the  risks  associated  with  organizations  dealing  with  system 
or  software  [1 0].  Moreover,  1 6085  is  specifically  designed  to  be 
used  in  conjunction  with  ISO  12207-2008. 

Thus,  the  recommendations  of  the  standard  can  be  directly 
aligned  with  the  risk  management  activities  specified  by  the 
1 2207  project  process  area  (6.4).  When  used  with  ISO  1 2207- 
2008,  the  1 6085  standard  assumes  that  necessary  manage¬ 
rial  and  technical  processes  to  perform  the  treatment  of  risk 
are  called  out  by  the  ISO  1 2207-2008  model.  The  addition  of 
the  risk  management  component  to  the  standard  procurement 


model  represented  in  the  12207  agreement  processes  provides 
a  complete  set  of  practices  for  ICT  SCRM. 

Creating  an  Instructional  Model  for  SCRM 

SCRM  issues  are  different  for  the  acquirer,  supplier,  and 
integrator.  In  addition,  there  are  at  least  four  different  types  of 
environments  that  require  a  specific  approach  to  SCRM:  high 
assurance  (trusted),  government-off-the-shelf,  commercial- 
off-the-shelf,  and  services.  Given  that  diversity,  our  aim  was  to 
derive  a  standard  set  of  activities  and  practices  from  the  two 
standards  discussed  in  the  prior  section.  Our  goal  was  to  derive 
a  point  of  reference  for  content  and  teaching  development. 

The  relevant  lifecycle  process  activities  that  were  incorporated 
in  our  approach  are  from  the  1 2207-2008:  Agreement,  Reuse, 
Technical,  and  Supporting  and  Project  Management  process  ar¬ 
eas.  These  recommendations  were  integrated  with  the  ICT  Risk 
Management  process  recommendations  that  are  specified  by 
ISO  16085.  The  content  model  derived  from  integrating  these 
two  references  ultimately  leads  to  a  set  of  lifecycle  activities  and 
practices,  which  can  form  a  starting  point  for  development  of  a 
complete  BOK  for  management  of  supply  chain  risk. 

Once  such  a  BOK  has  been  perfected,  explicit  learning  be¬ 
haviors  can  be  derived  for  each  content  item.  Then,  appropriate 
standard  instructional  content  can  be  designed  and  created  to 
reinforce  each  behavior  along  with  a  set  of  proficiency  require¬ 
ments  specified  for  each  action.  Instructional  content  can  be 
customized  from  the  BOK  to  address  each  situation  in  which 
it  will  be  applied.  The  approach  to  content  delivery  can  be 
referenced  to  learning  and  proficiency  specifications.  From  an 
evaluation  standpoint,  the  ability  to  perform  each  task  can  be 
characterized  as  a  nominal  set  of  observable  actions.  The  knowl¬ 
edge  needed  to  perform  each  task  and/or  the  skill  required  to 
perform  each  task  can  be  characterized  as  an  ordinal  judgment 
of  proficiency. 

The  list  below  summarizes  the  general  subject  areas  that 
evolved  from  our  process  of  creating  an  instructional  model  for 
SCRM,  using  the  recommendations  of  the  two  standards. 

Subject  Area  One:  Project  Initiation  and  Planning 

•  Strategic  management  and  policy 

•  Project  management 

•  Business  and  assurance  case  development 

•  Supply  chain  component  definition  and  labeling 

•  Threat/risk  and  mitigation  identification  and  planning 

Subject  Area  Two:  Product  Requirements  Communication 

•  Requirements  elicitation  and  specification 

•  Requests  for  proposals  (RFP)  documentation 

•  Statement  of  work  (SOW)  documentation 

•  Project  assurance  criteria  development  (including  SCRM) 

•  Project  measurement  and  metrics  development 
(including  SCRM) 

•  Formalization  and  documentation  of  product  assurance 
case  requirements 

•  Preparation  and  documentation  of  acceptance  criteria 
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Subject  Area  Three:  Source  Selection  and  Contracting 

•  Source  selection  process 

•  Source  evaluation  process 

•  Contract  negotiation 

•  Contract  writing 

•  Lifecycle  contract  management  planning 

•  Lifecycle  project  management  planning 

Subject  Area  Four:  Supplier  Contract  Execution 

•  Document  framework  for  ICT  project  management. 

•  Document  plan  to  manage  the  quality  and  security 
of  the  project. 

•  Implement  and  execute  the  project  management  plan(s). 

•  Monitor  and  control  progress  throughout  the  contracted 
lifecycle. 

•  Manage  and  control  the  subcontractors. 

•  Interface  with  the  independent  verification,  validation, 
or  test  agent. 

•  Coordinate  contract  review  activities  and  interfaces. 

•  Conduct  joint  reviews  in  accordance  with  ISO  standard 
specifications. 

•  Perform  verification  and  validation  to  satisfy  that 
requirements  are  met. 

Subject  Area  Five:  Customer  Agreement  Monitoring 

•  Monitor  the  supplier’s  activities  in  accordance  with  the 
contracted  software  assurance  process 

•  Develop  plan  to  supplement  monitoring  with  verification  and 
validation  as  needed 

•  Develop  plan  to  ensure  necessary  information  is  provided  in 
a  timely  manner 

Subject  Area  Six:  Customer  Acceptance 

•  Plan  acceptance  process  based  on  contracted  acceptance 
strategy  and  criteria 

•  Plan  test  cases,  test  data,  test  procedures,  and 
test  environment 

•  Conduct  acceptance  review  and  acceptance  testing 
of  the  deliverable 

•  Accept  product  from  supplier  when  all  acceptance 
conditions  are  satisfied 

•  Plan  to  migrate  product  from  supplier  to  customer 

Subject  Area  Seven:  Project  Closure 

•  Make  payment  or  provide  other  agreed  consideration  to 
the  supplier 

•  Install  the  product  in  accordance  with  established 
requirements 

•  Ensure  agreement  terminates  when  payment  is  made 

•  Transfer  legal  responsibility  for  the  product  or  service  to 
the  customer 

•  Provide  assistance  to  the  customer  in  support  of  the 
delivered  product 


The  subject  areas  and  detailed  activities  and  practices  of 
SCRM  provide  support  for  the  development  of  a  formal  discipline 
of  SCRM.  Once  the  discipline  is  codified,  this  material  can  be  in¬ 
tegrated  into  traditional  ICT  education  and  training  programs.  ISO 
1 2207-2008  provides  a  commonly  accepted  definition  of  best 
practices  for  ICT  acquisition  and  supply,  while  activities  and  tasks 
specified  in  ISO  1 6085  provide  an  excellent  collection  of  assur¬ 
ance  practices  for  ICT  work.  This  makes  it  possible  to  construct 
a  detailed  picture  of  SCRM  practices  and  activities  that  can  be 
used  in  building  an  SCRM  body  of  knowledge. 

Example  Activities  and  Practices  for  SCRM 

Procurement  Program  Initiation  and  Planning 

•  Develop  the  concept  to  acquire  (business  case). 

•  Define  project  scope  and  boundaries. 

•  Develop  an  acquisition  strategy  and/or  plan. 

•  Define  constraints. 

•  Make  decision  to  contract. 

•  Identify  and  mitigate  outsourcing  definitions. 

•  Install  risk  management  process. 

•  Perform  product  assurance  risk  assessment. 

•  Develop  product  assurance  risk  mitigation  strategies. 

•  Ensure  product  assurance  risk  monitoring. 

Product  Requirements  Communication 

•  Issue  written  requests  to  prospective  suppliers. 

•  Standardize  elements  of  the  RFP. 

•  Document  SCRM  needs  and  requirements  in  the  RFP. 

•  Specify  SCRM  terms  and  conditions. 

•  Specify  information  security  features. 

•  Specify  acceptance  criteria  for  COTS  integrations. 

•  Implement  common  criteria  (if  required). 

•  Create  a  specification. 

•  Specify  SCRM  measures  and  metrics. 

•  Create  assurance  language  for  a  statement  of  work  (SOW). 

•  Assure  requirements  for  C&A  in  SOW. 

•  Ensure  SOW  specifies  SCRM  education  and  training. 

•  Develop  SOW  to  acquire  COTS. 

•  Provide  SCRM  language  in  instructions  to  suppliers. 

•  Ensure  response  reflects  the  specified  capabilities. 

•  Ensure  supplier  has  submitted  adequate  information. 

•  Specify  initial  product  architecture. 

•  Specify  product  assurance  case  management 
procedure. 

•  Specify  product  assurance  lifecycle. 

•  Specify  product  requirements  and  traceability  criteria. 

Source  Selection  and  Contracting 

•  Specify  evaluation  criteria. 

•  Ensure  standard  product  assurance  evaluation  criteria. 

•  Specify  assurance  criteria  in  the  Source  Selection  Plan. 

•  Perform  contract  negotiations. 

•  Perform  project/contract  management. 


26  CrossTalk-March/April  2013 


SUPPLY  CHAIN  RISK  MANAGEMENT 


•  Plan  to  oversee  product  assurance  reviews  and  audits. 

•  Ensure  competent  product  assurance  professional(s). 

•  Oversee  the  supplier’s  delivery  of  product  assurance. 

•  Define  the  rate  at  which  the  supplier  will  provide 
assurance  statements. 

•  Define  how  performance  will  be  evaluated  if  an 
SLA  is  used. 

•  Define  the  role  that  product  assurance  plays  in 
product  C&A. 

•  Define  how  the  product  architecture  will  be  managed. 

•  Define  what  will  be  reviewed  from  an  assurance 
perspective. 

•  Define  how  often  the  risk  management  plan  will 
be  updated. 

•  Define  how  often  the  product  assurance  risks  will 
be  evaluated. 

•  Devise  an  issues  resolution  plan  and  process. 

•  Define  circumstances  for  intelligence  updates. 

•  Define  how  corrective  actions  will  be  monitored. 

•  Define  how  product  assurance  savings  will  be 
measured. 

•  Define  how  experience  level  will  be  monitored. 

•  Define  how  to  identify  key  product  personnel. 

•  Define  how  key  personnel  will  be  monitored. 

•  Define  how  assurance  training  program  will  be 
monitored. 

Supplier  Contract  Execution 

•  Create  a  management  framework  for  the  ICT  project. 

•  Select  a  lifecycle  model. 

•  Select  processes,  activities,  and  tasks  and  map  them 
to  lifecycle  model. 

•  Develop  a  plan  to  manage  the  quality  and  security  of 
the  project. 

•  Develop  document  project  management  plan(s). 

•  Implement  and  execute  the  project  management 
plan(s). 

•  Monitor  and  control  progress  throughout  the 
contracted  lifecycle. 

•  Develop  the  software  product  using  internal  resources. 

•  OR  develop  the  software  product  by  subcontracting. 

•  Buy  off-the-shelf  software  products  from  internal  or 
external  sources. 

•  Monitor  the  progress  of  the  project. 

•  Manage  and  control  the  subcontractors. 

•  Ensure  all  contractual  requirements  are  passed 
to  subcontractors. 

•  Interface  with  the  independent  verification,  validation, 
or  test  agent. 

•  Interface  with  other  parties  as  specified  in  the 
contract  and  project  plans. 

•  Coordinate  contract  review  activities  and  interfaces. 

•  Conduct  joint  reviews  in  accordance  with  ISO 
standard  specifications. 


•  Perform  verification  and  validation  to  satisfy  that 
requirements  are  met. 

•  Make  reports  available  as  specified  in  the  contract. 

Customer  Agreement  Monitoring 

•  Monitor  supplier’s  activities  using  the  Software  Review 
Process. 

•  Supplement  monitoring  with  verification  and  validation 
as  needed. 

•  Ensure  necessary  information  is  provided  in  a  timely  manner. 

Customer  Acceptance 

•  Prepare  for  acceptance  based  on  the  acceptance  strategy. 

•  Prepare  test  cases,  test  data,  test  procedures,  and  test 
environment. 

•  Define  the  extent  of  supplier  involvement  in  acceptance. 

•  Conduct  acceptance  review  and  acceptance  testing  of 
the  deliverable. 

•  Accept  product  from  supplier  when  all  acceptance 
conditions  are  satisfied. 

•  Arrange  to  make  customer  responsible  for  configuration 
management. 

Project  Closure 

•  Make  payment  or  provide  other  agreed  consideration  to 
the  supplier. 

•  Install  the  product  in  accordance  with  established 
requirements. 

•  Ensure  agreement  terminates  when  payment  is  made. 

•  Transfer  responsibility  for  the  product  or  service  to 
the  customer. 

•  Provide  assistance  to  the  customer  in  support  of  the 
delivered  product. 

Conclusion 

We  have  proposed  a  set  of  SCRM  activities  and  practices  in 
this  paper.  These  activities  and  tasks  comprise  an  initial  picture 
of  the  knowledge  needed  to  correctly  and  effectively  conduct 
a  practical  SCRM  process.  We  derived  this  set  of  activities  and 
practices  from  established  models  of  practice  for  acquisition 
and  supply  of  software  and  systems,  along  with  additional  risk 
control  elements.  We  believe  that  it  will  be  possible  to  create 
a  true  body  of  knowledge  in  SCRM  using  this  set  as  a  starting 
point.  SCRM  is  clearly  a  huge  field  composed  of  a  number  of 
not  clearly  related  subjects.  The  first  step  in  creating  a  body  of 
knowledge  for  the  field  is  to  provide  a  top-level  classification 
structure  of  its  practices  and  activities,  which  we  propose  in 
this  paper. 
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Cyber  Challenges 
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Abstract.  While  security  in  the  physical  world  can  be  addressed  using  controls 
such  as  guns,  gates,  and  guards,  the  virtual  world  requires  other  mechanisms  to 
ensure  the  confidentiality,  availability,  and  integrity  of  products  and  services.  Much 
of  what  today’s  products,  services,  infrastructures,  and  institutions  do  is  automated 
by  software,  thereby  increasing  our  dependence  on  how  safety  and  security  are  ad¬ 
dressed  in  the  virtual  world.  As  software  continues  to  evolve  and  we  find  new  ways 
to  leverage  the  virtual  world  in  our  day-to-day  activities,  the  volume  of  and  our  reli¬ 
ance  on  software  grows  exponentially.  Therefore,  it  is  increasingly  important  to  have 
confidence  that  products  operate  as  intended  and  only  as  intended  to  ensure  the 
resilience  and  reliability  of  the  functions  they  support.  Much  of  software  is  acquired 
forcing  consideration  of  these  critical  qualities  into  the  supply  chain.  Achieving  such 
confidence  ultimately  relies  on  good  system  and  software  engineering  knowledge, 
processes,  and  technology.  Fortunately,  many  resources  are  available.  This  article 
provides  a  brief  survey  of  some  of  these  resources,  such  as  process  capability 
frameworks,  secure  lifecycle  practices,  and  implementation  approaches. 

Introduction 

Global  markets,  funding,  and  shareholder  commitments  often 
drive  companies  to  get  their  products  and  services  out  to  the 
market  quickly.  However,  ignorance  of  vulnerabilities,  heuristics, 
and  biases  [1]  result  in  exploitable  weaknesses  that  may  affect 
the  safety  and  security  as  well  as  the  reputation  of  products.  It  is 
the  market  demand  for  newer,  faster,  and  cooler  that  drives  the 
pace  of  technology.  However,  software  developers  make  it  hap¬ 
pen.  We  find  a  gap  in  security  and  safety  in  the  products  today 
because  of  the  lack  of  both  market  requirements  and  developer 
skills.  Much  of  software  is  acquired  forcing  consideration  of 
these  critical  qualities  into  the  supply  chain. 

Today  consumers  expect  products  to  have  safety  and  security 
built  in.  They  take  such  quality  attributes1  for  granted.  However, 
over  half  of  the  240  companies  surveyed  in  a  recent  Forrester 
study  reported  at  least  one  web  application  security  incident 
since  last  year.  The  most  frequently  cited  causes  were  misused 
default  password  accounts,  SQL  injection-related  vulnerabilities, 
and  security  misconfigurations  [2].  This  is  particularly  challeng¬ 
ing  since  many  organizations  acquire  software  products  and 
must  ensure  their  expectations  are  met  through  acquisition 
where  requirements  and  design  expectations  must  be  clearly 
conveyed. 

Developers  initially  tend  to  focus  exclusively  on  product 
functionality,  treating  safety  and  security  as  something  to  test 
at  the  end  of  product  development.  In  other  words,  they  miss 
the  opportunity  to  identify  and  mitigate  vulnerabilities  early  in 
the  development  lifecycle.  If  problems  are  not  detected  and 
addressed  early,  they  frequently  are  too  expensive  to  fix  when 
discovered  later  in  the  lifecycle. 


The  Threat  Landscape 

According  to  the  October  201  1  report  from  the  Office  of  the 
National  Counterintelligence  Executive  to  Congress  on  For¬ 
eign  Economic  and  Industrial  Espionage,  “Because  the  United 
States  is  a  leader  in  the  development  of  new  technologies  and 
a  central  player  in  global  financial  and  trade  networks,  foreign 
attempts  to  collect  U.S.  technological  and  economic  information 
will  continue  at  a  high  level  and  will  represent  a  growing  and 
persistent  threat  to  U.S.  economic  security.  The  nature  of  the 
cyber  threat  will  evolve  with  continuing  technological  advances 
in  the  global  information  environment  [3].” 

The  report  further  identified  specific  technology  areas  (i.e.,  in¬ 
formation  and  communications  technology,  military  technologies, 
clean  technologies,  advanced  materials  and  manufacturing  tech¬ 
niques,  healthcare,  pharmaceuticals,  and  agricultural  technology) 
and  types  of  business  information  (i.e.,  energy  and  other  natural 
resources,  business  deals,  and  macroeconomic  information)  as 
targets  of  foreign  attack. 

For  the  past  five  years,  Verizon  has  published  its  annual  Data 
Breach  Investigations  Report.  In  these  reports,  Verizon  analyzes 
the  causes  of  breaches  and  provides  recommendations  for  how 
they  could  have  been  prevented.  These  studies  provide  valuable 
insight  into  the  level  of  complexity  in  today’s  attacks  as  well  as 
organizational  behaviors  that  either  enable  or  hinder  attacks. 


2011  Verizon  Data  Breach 
Investigations  Report  [4] 

2012  Verizon  Data  Breach 
Investigations  Report  [5] 

What 

commonalities 

exist? 

■  83%  of  victims  were  targets  of 
opportunity 

■  92%  of  attacks  were  not  highly 
difficult 

■  86%  of  incidents  were  discovered 
by  a  third  party 

■  96%  of  breaches  were  avoidable 
through  simple  or  intermediate 
controls 

■  79%  of  victims  were  targets  of 
opportunity  (-4%) 

■  96%  of  attacks  were  not  highly 
difficult  (+4%) 

■  92%  of  incidents  were  discovered 
by  a  third  party  (+6%) 

■  97%  of  breaches  were  avoidable 
through  simple  or  intermediate 
controls  (+1  %) 

How  do 

breaches 

occur? 

■  50%  utilized  some  form  of  hacking 

■  49%  incorporated  malware 

■  81  %  utilized  some  form  of  hacking 
(+31%  increase) 

■  69%  incorporated  malware  (+20% 
increase) 

(lower  percentages  included  physical 
attacks,  privilege  misuse,  and  social 
tactics) 

(lower  percentages  included  physical 
attacks,  privilege  misuse,  and  social 
tactics) 

Table  1.  Data  from  Verizon  Data  Breach  Investigations  Report 


Good  Development  Practice 

To  assure  safe  and  secure  products  and  services,  good 
development  practice  must  be  used  from  the  beginning.  Safety 
and  security  should  be  viewed  as  enablers,  not  constraints 
because  they  impact  an  organization’s  goals  and  reputation.  One 
general  principle  that  facilitates  stakeholders  to  focus  on  safety 
and  security  throughout  the  software  lifecycle  is  to  use  itera¬ 
tive,  continuous,  and  evolutionary  approaches  to  direct  product 
acquisition,  development,  and  delivery.  Such  approaches  provide 
developmental  agility,  which  is  helpful  to  effectively  address  high 
uncertainty  and  to  respond  to  unanticipated  change. 

Good  development  practice  that  is  specific  to  safety  and 
security  includes: 

•  Provide  early  and  careful  consideration  to  quality  attributes. 
Experience  shows  that  safety  and  security  cannot  be  added  at 
the  end  of  the  development  lifecycle  [6].  Rather,  products  need 
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to  be  developed  with  safety  and  security  in  mind  from  inception 
through  disposal. 

•  Provide  early  and  careful  attention  to  an  architecture  that 
effectively  addresses  tradeoffs  among  quality  attributes  and 
product  functionality. 

•  “Step  to  the  left."  Most  human  error  can  be  best  detected 
shortly  after  it  is  committed  (and  it  is  more  cost-effective  to 
remove).  Organizations  need  to  make  the  most  of  this  principle 
when  detecting  errors  in  individual,  team,  and  organizational 
processes. 

•  Use  processes  that  encourage  careful  consideration  of 
how  errors  may  be  introduced,  detected,  removed,  and  pre¬ 
vented.  For  example,  explicit  task  kickoff  and  inspection  check¬ 
lists  can  be  incorporated  at  multiple  points  in  the  software 
development  lifecycle  (SDLC)  to  sustain  attention  on  common 
error  patterns  affecting  quality.  Also,  requirements  elicitation, 
architecture,  risk  management,  and  decision  analysis  process¬ 
es  (and  thus  software  development  teams)  should  encourage 
explicit  attention  to  safety  and  security  (as  well  as  other  critical 
quality  attributes). 

•  View  safety  and  security  as  an  enabler  of  the  organization’s 
core  mission  and  objectives  and  not  as  a  constraint  on  creativ¬ 
ity  and  innovation.  Make  sure  these  attributes  are  common¬ 
place  in  the  development  of  all  products  and  services. 

•  Use  reviews  and  code  analysis  tools  to  reduce  code- 
induced  vulnerabilities  hereby  developing  higher  quality  code. 

•  Be  informed;  what  you  do  not  know  can  kill  you.  A  team’s 
overconfidence  is  an  attacker’s  best  friend.  Most  exploitable 
errors  are  not  the  result  of  a  lack  of  creativity  or  motivation 
but  the  lack  of  knowledge  about  vulnerabilities  and  human 
oversights.  Better  knowledge,  processes,  and  technology  can 
help  overcome  these  weaknesses  and  the  limits  of  our  self- 
awareness  [1],  Learn  to  think  like  an  attacker. 

Changing  Technology 

Opportunities  and  challenges  arise  with  our  ever-increasing 
reliance  on  technology.  Digital  thievery  and  espionage  are  con¬ 
cerns  that  organizations  have  to  think  about  for  their  employees. 
The  nature  of  cyber  threats  is  changing  at  an  alarming  rate.  You 
must  commit  to  knowing  as  much  about  security  as  the  attack¬ 
ers  know  to  hope  to  stay  ahead  of  them.  Learn  what  resources 
are  available  and  weave  it  into  your  learning  and  business 
processes.  Your  development  practices  must  consider  security 
issues  as  they  relate  to  technology  as  well  as  to  what  others 
have  learned  and  are  sharing  about  safety  and  security. 

According  to  a  Forrester  study,  “ROI  was  greater  for  those 
who  employed  a  coordinated,  prescriptive  approach  [7].” 

Unfortunately,  many  organizations  are  unable  to  communicate 
the  return  on  investment  effectively  enough  to  gain  manage¬ 
ment  support  in  driving  the  adoption  of  more  secure  practices. 
Lack  of  management  support  and  resistance  to  change  is  a  bar¬ 
rier  to  the  adoption  of  secure  development  methodologies. 

In  a  more  recent  Forrester  study,  challenges  contributing  to 
the  volume  of  insecure  software  included  [2]: 

•  Developers  being  unable  to  keep  pace  with  the  volume  of 
code  they  produce. 

•  Struggles  to  build  the  business  case  for  additional  funding. 

•  The  lack  of  adequate  tools. 
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Diversity  of  Resources 

Do  not  limit  yourself  to  the  perspectives  offered  by  only  one 
process  improvement  model.  As  George  Box  is  famous  for 
saying,  “All  models  are  wrong  but  some  are  useful  [8].”  Models 
often  become  more  useful  when  used  in  aggregate.  Process 
improvement  can  and  should  incorporate  knowledge  of  superior 
practice  and  vulnerabilities.  Process  measurement  can  help 
to  determine  the  effects  of  particular  development  practices, 
making  both  cause  and  effect  more  salient,  and  elevating  the 
state  of  software  programming  from  ad-hoc  practices  toward 
evidence-based  software  development 

The  DHS,  NIST  and  the  DoD  are  tackling  this  problem  with 
their  Software  Assurance  (SwA)  working  groups  and  forums, 
which  seek  to  engage  multiple  communities  working  together 
to  develop  solutions  and  guidelines  that  reduce  software 
vulnerabilities,  minimize  exploitation,  and  improve  the  routine 
development  and  deployment  of  trustworthy  software  products. 
Together,  these  activities  will  enable  more  secure  and  reliable 
software  that  supports  mission  requirements  across  enterprises 
and  the  critical  infrastructure. 

It  is  important  to  be  aware  of  activities  associated  with  safety 
and  security  and  to  ensure  your  organization  has  the  capabil¬ 
ity  to  achieve  your  software  assurance  goals.  To  help  with  this 
awareness,  the  DHS  SwA  Processes  and  Practices  Working 
Group  has  synthesized  the  contributions  of  leading  govern¬ 
ment  and  industry  experts  into  the  set  of  high-level  goals  and 
supporting  practices  shown  in  Figure  1.  Using  these  practices, 
organizations  can  identify  their  assurance  practices  implementa¬ 
tion  baseline. 

The  Assurance  Process  Reference  Model  [9]  addresses  as¬ 
surance  in  the  organization  from  executive  to  developer.  It  can 
be  used  to  help  organizations  conduct  a  gap  analysis  of  their 
existing  practices  versus  industry  recognized  security  practices. 
The  results  of  the  gap  analysis  can  then  be  used  to  prioritize 
and  track  SwA  implementation  efforts. 

What  CM  Ml  Says  About  Security 

CM  Ml®  models  reflect  what  leading  organizations  do  to  ac¬ 
quire,  develop,  and  sustain  software-intensive  products  and  ser¬ 
vices.  It  is  not  surprising  that  safety  and  security  are  addressed 
implicitly  (and  sometimes,  explicitly)  in  CMMI  models. 

Safety  and  security  are  regarded  as  quality  attributes  in  CMMI 
models.  This  term  is  mentioned  extensively  in  the  Acquisition 
Engineering  process  areas  of  the  CMMI  for  Acquisition  model 
[10],  the  Engineering  process  areas  of  the  CMMI  for  Develop¬ 
ment  model  [1  1],  and  the  Service  System  Development  process 
area  of  the  CMMI  for  Services  model  [12].  In  particular,  CMMI 
for  Development  includes  coverage  of  quality  attribute  require¬ 
ments  (and  thus  safety  and  security  requirements). 

Safety  and  security  are  addressed  at  an  abstract  level.  Such 
coverage  makes  sense  in  a  CMMI  model  because  it  is  rare  that 
products  need  to  be  only  safe  or  secure.  Instead,  desired  quality 
attributes  are  addressed  through  careful  architecture  evaluation 
and  tradeoffs.  This  more  holistic  treatment  of  quality  attributes 
is  essential  to  effective  product  design  and  is  addressed  in  the 
201  1  SEI  Webinar  Capability  Maturity  Model  Integration  VI. 3 
and  Architecture-Centric  Engineering  [6]. 
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Define  Business  Goals 


Development  Organization 


n 


DO  1  Establish  the  assurance 
resources  to  achieve  key 
business  objectives 
DO  2  Establish  the  environment 
to  sustain  the  assurance 
program  within  the 
organization 


Development  Project 

DP  1  Identify  and  manage  risks 
due  to  vulnerabilities 
throughout  the  product 
and  system  lifecycle 

DP  2  Establish  and  maintain 
assurance  support  from 
the  project 

DP  3  Protect  project  and 

organizational  assets 


Prioritize  funds 

and  manage 

risks 


Enterprise  Assurance  Support 

ES  1  Establish  and  maintain 
organizational  culture 
where  assurance  is  an 
integral  part  of 
achieving  the  mission 

ES  2  Establish  and  maintain 
the  ability  to  support 
continued  delivery  of 
assurance  capabilities 

ES  3  Monitor  and  improve 

enterprise  support  to  IT 
assets 


Acquisition  and  Supplier 
Management 

AM  1  Select,  manage,  and 
use  effective  suppliers 
and  third  party 
applications  based 
upon  their  assurance 
capabilities. 


Development  Engineering 

DE  1  Establish  assurance 
requirements 

DE  2  Create  IT  solutions  with 
integrated  business 
objectives  and 
assurance 

DE  3  Verify  and  Validate  an 
implementation  for 
assurance 


Enable 

Resilient 

Technology 


Sustained 
environment  to 
achieve  business 

goals  through 

technology 


Figure  1 .  The  Assurance  Process  Reference  Model 


Security  (and  sometimes  safety)  is  explicitly  covered  in 
CMMI  in  the  following: 

•  Example  standards  that  are  applicable  to  the  organizational 
processes  as  listed  in  the  Organizational  Process  Focus 
process  area. 

•  A  special  section  of  the  References  that  addresses  Infor¬ 
mation  Assurance/Information  Security  Related  Sources. 

•  A  discussion  of  information  system  vulnerabilities  that 
appears  in  the  Measurement  and  Analysis  process  area. 

•  Work  environment  standards  in  the  Organizational  Process 
Definition  and  Integrated  Project  Management  process 
areas. 

•  Example  quality  attributes  in  the  Engineering  process  areas. 

•  As  a  strategic  consideration  in  the  Project  Planning  and 
Work  Planning  process  areas. 

•  Requirements  and  procedures  that  are  considered  as  part 
of  data  management  practices. 

What  Does  This  Imply? 

CMMI  addresses  the  critical  broader  (system)  view  of  product 
and  service  scope,  functionality,  and  quality  attributes  and  how 
attention  to  all  of  these  are  necessary  to  make  appropriate  deci¬ 
sions  and  tradeoffs  as  the  product  or  service  is  engineered  and 
developed.  However,  CMMI  does  not  provide  specific  guidance 
about  individual  quality  attributes  or  information  about  their 
relationships.  Safety  and  Security  are  addressed  in  an  informa¬ 
tive,  not  normative,  manner.  You  must  look  elsewhere  for  explicit 
guidance  about  what  to  do  in  your  organizational,  team,  or 
individual  processes  about  safety  and  security  because  CMMI  is 
relatively  silent  when  your  focus  shifts  from  the  overall  balance 
of  quality  attributes  to  individual  quality  attributes. 


What  Additional  Practices  Help  to  Build  Safe  and 
Secure  Products? 

In  recent  years,  multiple  frameworks  were  developed  that 
explicitly  focus  on  practices  and  guidance  for  addressing  safety 
and  security.  These  frameworks  can  be  grouped  into  three 
categories: 

•  Process  capability  frameworks. 

•  Secure  lifecycle  practices. 

•  Implementation  approaches. 

Process  capability  frameworks  include: 

•  Resilience  Management  Model-a  model  that  addresses 
converging  security,  business  continuity,  and  IT  operations  in 
support  of  operational  risk  management  [13]. 

•  Assurance  Process  Reference  Model-a  model  that  syn¬ 
thesizes  the  contributions  of  leading  government  and  industry 
experts  into  a  set  of  high-level  goals  and  practices  to  address 
software  assurance  (Figure  1)  [9]. 

•  Assurance  for  CMMI-a  thread  of  assurance  practices  that 
can  be  overlaid  on  an  existing  CMMI  implementation.2 

•  +Safe  and  +Secure3-white  papers  that  extend  CMMI  models  by 
providing  a  set  of  process  areas  specific  to  safety  and  security  [1 4]. 

References  for  secure  lifecycle  practices  include: 

•  Microsoft  Security  Development  Lifecycle-a  software 
development  security  assurance  process  consisting  of  security 
practices  grouped  into  7  phases:  training,  requirements,  de¬ 
sign,  implementation,  verification,  release,  and  response  [15]. 

•  SAFECode-a  global,  industry-led  effort  to  identify  and  pro¬ 
mote  best  practices  for  developing  and  delivering  more  secure 
and  reliable  software,  hardware,  and  services4 
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Figure  2.  Configuration  of  Resources  Addressing  Process  Improve¬ 
ment,  Quality,  and  Security 


Implementation  approaches  include. 

•  Open  Software  Assurance  Maturity  Model-an  open 
framework  that  helps  organizations  to  formulate  and  implement 
a  strategy  for  software  security  that  is  tailored  to  the  specific 
risks  facing  the  organization  [15]. 

•  Building  Security  In  Maturity  Model-a  descriptive  model  that 
describes  the  specific  activities  that  organizations  can  engage  in 
to  improve  and  mature  their  software  security  posture  [1 6]. 

•  TSP  Secure-an  extension  of  the  SEI  Team  Software 
Process  (TSP)  methodology  that  achieves  the  development  of 
secure  software  systems  by  incorporating  the  planning,  pro¬ 
cess,  quality,  measurement,  and  tracking  frameworks  of  TSP 
and  generating  the  practices  and  artifacts  required  to  satisfy  a 
maturity  level  3  appraisal  [1 7,  18]. 

•  CERT  Secure  Coding  Standards-a  wiki-based  website 
that  supports  a  broad-based  community  of  more  than  500 
contributors,  including  security  researchers,  language  experts, 
and  software  developers  [19]. 

•  Open  Web  Application  Security  Project-an  open  commu¬ 
nity  dedicated  to  enabling  organizations  to  conceive,  develop, 
acquire,  operate,  and  maintain  applications  that  can  be  trusted 
as  well  as  to  provide  tools,  documents,  forums,  and  chapters 
free  to  anyone  interested  in  improving  application  security  [15]. 

•  Build  Security  In-a  collaborative  effort  that  provides  prac¬ 
tices,  tools,  guidelines,  rules,  principles,  and  other  resources 
that  software  developers,  architects,  and  security  practitioners 
can  use  to  build  security  into  software  during  every  phase  of  its 
development  [20]. 

•  Strengthening  Ties  between  Process  and  Security-a 
summary  of  key  accomplishments  in  linking  security,  the  SDLC, 
and  process  improvement,  including  an  industry-led  initiative  to 
harmonize  security  practices  with  CMMI,  the  use  of  assurance 
cases,  and  NIST  security  considerations  in  the  SDLC  [21]. 

•  Security  Quality  Requirements  Engineering-a  process 
model  that  provides  a  means  for  eliciting,  categorizing,  and 


prioritizing  security  requirements  for  information  technology 
systems  and  applications  [22]. 

•  Correctness  by  Construction-a  method  of  building  software 
with  demonstrable  integrity  for  security-  and  safety-critical  applica¬ 
tions  by  combining  formal  methods  and  Agile  development  [23]. 

The  challenge  that  many  organizations  face  is  defining 
their  business  goals  and  objectives  with  respect  to  safety  and 
security.  These  goals  and  objectives,  along  with  organizational 
policies  and  processes,  are  critical  to  identifying  the  regula¬ 
tions,  standards,  and  best  practices  that  are  needed  to  enable 
organizations  to  build  safe  and  secure  products.  It  is  important 
to  tailor  one  or  more  frameworks,  such  as  CMMI,  to  provide  both 
a  foundation  and  the  flexibility  for  organizations  to  respond  to 
internally  or  externally  driven  changes  in  business  goals  and  ob¬ 
jectives.  Figure  2  illustrates  how  existing  resources  fit  together 
to  address  process  improvement,  product  quality,  and  security 

Summary 

With  the  ever-increasing  reliance  on  safety  and  security  in 
products  and  services,  CMMI  provides  a  needed  starting  point, 
but  it  is  not  sufficient.  A  learning,  knowledgeable,  and  resource- 
aware  mindset  is  also  required.  A  variety  of  approaches  and 
tools  are  available  to  help  you  be  successful.  Very  little  of  these 
approaches  and  tools  are  rocket  science  but  their  use  requires  a 
commitment  by  the  organization.  For  a  software  product  acquired 
through  a  supply  chain,  the  acquisition  mechanisms  need  to  incor¬ 
porate  effective  supply  chain  risk  management  to  ensure  the  sup¬ 
plying  organization  is  performing  critical  processes  and  practices. 

As  a  starting  point,  identify  the  policies,  standards,  and  busi¬ 
ness  objectives  that  will  drive  excellence  in  your  organization. 
CMMI  and  other  lifecycle  standards  (e.g.,  ISO/IEEE  15288) 
provide  the  foundation  and  flexibility  to  build  safety  and  security 
into  an  organization’s  lifecycle  processes.  You  can  then  identify 
which  of  the  available  resources  will  best  drive  development  of 
safe  and  secure  products  and  services  in  your  organization. 

Process  and  product  assessments  are  valuable  to  understanding 
potential  vulnerabilities  and  risks.  Organizations  need  to  explicitly 
link  their  objectives  to  the  assessments  to  use  them  effectively  The 
assessment  results  can  help  in  the  evaluation  of  resources  that 
help  in  developing  better  products  and  services.  There  are  many 
different  approaches  for  addressing  safety  and  security;  no  single 
approach  addresses  the  needs  of  all  audiences  and  organizations. 
The  challenge  for  you  is  to  pick  the  approaches  that  work  best  in 
your  respective  environments.  This  article  provides  an  overview  of 
some  of  the  resources  available  because  today  most  organizations 
are  not  taking  advantage  of  the  guidance  that  is  freely  available. 
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Disclaimer: 

CM  Ml®  is  registered  in  the  U.S.  Patent  and  Trademark  Office 
by  Carnegie  Mellon  University.^ 


1.  The  term  quality  attributes  is  defined  in  CM  Ml  models  as  “A  property  of  a  product 
or  service  by  which  its  quality  will  be  judged  by  relevant  stakeholders.  Quality 
attributes  are  characterizable  by  some  appropriate  measure.  Quality 

attributes  are  non-functional,  such  as  timeliness,  throughput,  responsiveness, 
security,  modifiability,  reliability,  and  usability.  They  have  a  significant  influence  on 
the  architecture.” 

2.  A  pilot  version  of  Assurance  for  CM  Ml  was  released  in  March  2009.  Assurance  for 
CM  Ml  VI  .3  has  not  yet  been  published. 

3.  Siemens  AG,  Corporate  Technology  released  a  draft  report  entitled  +SECURE,  VI  .3, 
A  Security  Extension  to  CMMI-DEV,  VI .3  in  March  2012. 

4.  SAFECode,  whose  members  include  Adobe,  EMC  Corporation,  Juniper  Networks, 
Inc.,  Microsoft  Corporation,  Nokia,  SAP  AG,  Siemens  AG,  and  Symantec  Corporation, 
displays  its  work  on  their  website,  <http://www.safecode.org>. 
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Software  ID  Tags 
Support  Better 
Cyber  Security 

Steve  Klos,  TagVault.org 

John  Richardson,  Symantec  Corporation 

Abstract.  Would  you  fly  on  an  airline  that  did  not  verify  its  passengers’  identi¬ 
ties,  or  that  allowed  high-risk  passengers  onto  their  flights?  How  about  an  airline 
that  was  unable  to  scan  all  checked  luggage  for  known  threats,  or  was  unable  to 
ensure  that  each  piece  of  luggage  was  associated  with  a  known,  trusted  passen¬ 
ger?  This,  unfortunately,  is  the  position  that  IT  organizations  are  placed  into  every 
day  by  their  software  applications.  Software  publishers  do  not  typically  provide 
secure,  authoritative  information  that  provides  the  critical  information  IT  administra¬ 
tors  require  to  validate  the  authenticity  of  their  installed  software  applications  and 
their  executable  files  (program  files,  shared  libraries,  scripts,  etc.).  Typical  computer 
systems  such  as  a  laptop  with  an  operating  system  and  a  few  software  applications 
will  have  thousands  of  executable  files  installed  on  the  system  with  no  definitive 
way  to  authenticate  these  executable  files,  and  to  ensure  that  they  have  not  been 
modified  by  any  third  party.  To  improve  software  supply  chain  security,  IT  organi¬ 
zations  require  standardized,  authoritative  software  application  information  from 
software  publishers  that  allows  them  to  automate  the  following: 

•  Identifying  all  software  applications,  the  operating  system, 
their  revision  level,  and  all  software  updates  and  patches 

•  Associating  all  installed  files  to  specific  software 
applications,  or  to  the  operating  system 

•  Validating  that  all  installed  software  came  from  trusted 
software  suppliers 

•  Validating  the  authenticity  of  each  of  the  installed 
executable  files 

These  capabilities  are  fundamental  to  securing  computer  systems. 
IT  administrators  must  be  able  to  automate  these  capabilities  with 
a  high  level  of  confidence,  and  must  be  able  to  trust  that  their 
security  tools  can  identify  threats  or  known  vulnerabilities  quickly  and 
definitively.  However,  without  standardized,  authoritative  information 
provided  by  software  publishers  at  the  time  software  applications  are 
released,  it  is  remains  very  difficult  for  IT  administrators  to  fully  secure 
their  computer  systems. 

The  ISO/IEC  19770-2:2009  [1]  Software  Identification  Tagging 
standard  is  a  cross  platform  (Windows,  UNIX,  Linux,  Mac)  software 
identification  data  standard  that  provides  the  means  for  authoritative 
identification  of  software  applications,  operating  systems,  software 
updates,  and  patches.  Tags  also  provide  the  means  for: 

•  Validating  the  authenticity  of  install  media 

•  Automating  the  authenticity  validation  of  installed  application 
executable  files 


•  Automating  the  identification  of  installed  applications  with 
known  vulnerabilities  per  the  NIST  National  Vulnerability 
Database. 

This  article  provides  high-level  information  that  outlines  how 
software  identification  tags  provide  the  fundamental  building  blocks 
required  for  building  a  resilient  and  automated  IT  cyber  security  eco¬ 
system  based  on  information  that  is  very  easily  provided  by  software 
publishers. 

Standardizing  Software  Identification  in  an 
IT  Environment 

Today’s  software  and  computing  environments  are  large  and 
complex.  Software  applications  are  difficult  to  identify  and  track 
properly.  Non-standard  techniques  employed  by  software  pub¬ 
lisher  for  software  updates  and  patches  make  software  identifica¬ 
tion  even  more  difficult.  In  particular,  it  can  be  extremely  difficult 
to  determine  the  software  revision  level  and  whether  or  not  a 
software  update  has  been  properly  applied  to  a  system.  These 
complexities  make  it  extremely  difficult  for  IT  organizations  to 
ensure  the  most  fundamental  aspects  of  cyber  security— mainly: 

•  Ensuring  that  all  of  the  software  deployed  in  the  IT  environ 
ment  is  authentic,  unmodified,  and  from  a  trusted  supplier 

•  Ensuring  that  all  software  is  patched  and  that  all 
known  software  vulnerabilities  have  been  mitigated 

This  article  covers  the  following  four  critical  software  supply 
chain  security  areas,  and  compares  these  areas  to  the  security 
requirements  of  airline  travel: 

1)  Authoritative  Identification: 

Only  authorized  applications  from  trusted  suppliers  are  in¬ 
stalled  (verified  passengers). 

2)  Application  Associations: 

Correct  versions,  patches  and  third  party  components  are 
installed  and  related  to  their  parent  applications  (all  bags  can  be 
associated  with  passengers). 

3)  No  Corruptions  Allowed: 

Installed  files  or  third  party  components  have  not  been  modi¬ 
fied  (no  unknown  passengers). 

4)  No  Known  Threats: 

Known  application  vulnerabilities  have  been  resolved  (pas¬ 
sengers  and  bags  do  not  have  any  known  threats). 

Software  ID  Tags-What  Are  They? 

The  missing  link  in  today’s  computing  environment  is 
standardized,  authoritative  information  provided  by  software 
publishers  that  allow  IT  organizations  to  confidently  automate 
a  process  that  allows  only  trusted  applications  to  be  deployed 
in  their  environment,  ensure  that  all  application  executable  are 
authentic,  and  validate  that  the  correct  software  updates  have 
been  applied.  The  International  Organization  for  Standards  (ISO) 
published  the  ISO/IEC  19770-2:2009  Software  Identifica- 
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tion  (SWID)  Tagging  standard  enabling  software  publishers  to 
provide  standardized,  authoritative,  and  secure  application  identi¬ 
fication  information  in  a  consistent  and  secure  format  enabling 
security  and  asset  management  tools  to  authoritatively  identify 
installed  applications,  components,  and  patches,  and  associate 
these  items  with  files  installed  on  a  computing  device. 

This  article  does  not  provide  detailed  explanations  of  SWID 
tags-instead,  it  focuses  on  how  authoritative  software  identifi¬ 
cation  provided  by  SWID  tags  should  be  used  to  support  other 
security  standards  and  improve  overall  cyber  security  processes. 
For  more  detailed  information  on  SWID  tags,  refer  to  the 
TagVault.org  website  [2]. 

SWID  tags  are  not  silver  bullets  that  solve  all  cyber  security 
concerns.  Rather,  SWID  tags  provide  the  necessary  building 
blocks  upon  which  the  IT  community  can  build  a  more  secure 
infrastructure.  Each  of  the  following  sections  covers  a  different 
aspect  of  security  capabilities  supported  by  SWID  tags.  Provid¬ 
ing  SWID  tags  with  the  necessary  data  to  provide  all  four  critical 
functions  ensures  a  much  higher  degree  of  authoritative  and 
security  related  IT  capabilities.  Additionally,  material  covered  in 
this  article  is  focused  on  security  of  known  software  titles  from 
trusted  publishers.  If  a  computing  device  includes  unknown  soft¬ 
ware  installations,  SWID  tags  can  identify  that  fact,  but  will  not 
provide  more  than  the  identification  of  unknown  elements. 

1)  Authoritative  Identification 

When  flying,  a  passenger  must  carry  and  present  government 
issued  identification  documents.  This  provides  a  level  of  valida¬ 
tion  that  the  person  carrying  the  document  is  who  they  say  they 
are.  This  type  of  security  relies  on  a  trust  model  of  a  third  party 
validating  the  identity  of  the  passenger  and  some  method  to 
present  that  validation  information  to  an  unknown  third  party  (a 
security  screener  validating  a  driver’s  license  for  example). 

When  it  comes  to  software,  an  organization  that  publishes 
software  must  validate  who  they  are  and  that  they  have  the  nec¬ 
essary  trust  to  “digitally  sign”  SWID  tags.  This  is  done  through  a 
certificate  authority  that  validates  that  an  organization  is  real  and 
that  it  represents  (i.e.  owns)  the  organiza¬ 
tional  name. 

Once  a  certificate  authority  certifies  a 
digital  certificate  for  a  software  publisher, 
the  publisher  can  sign  data  with  a  private 
key  that  can  be  validated  using  the  cor¬ 
responding  trusted  public  key  as  shown 
in  Figure  1 .  SWID  tags  build  on  this  trust 
model  by  allowing  publishers  to  digitally  sign 
a  SWID  tag  that  is  associated  with  their 
software. 

Signed  SWID  tags  must  also  include  a 
timestamp  from  a  trusted  timestamp  server. 

This  ensures  two  things— first,  that  the 
signed  data  cannot  be  modified  by  anyone 
(even  the  publisher)  after  the  timestamp  is 
applied  without  a  third  party  being  able  to 
identify  that  data  has  been  modified.  Sec¬ 
ond,  it  allows  a  third  party  to  identify  that  the 


If  the  hashes  are  equal,  the  signature  is  valid. 


Digitally  signed  data 

Figure  1 :  Digital  Signatures  and  Digital  Signature  Verification  [3] 
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Figure  2:  Image  of  Trusted  Timestamping  process  [4] 
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Figure  3:  Unique  Products  Discovered  in  Discovery  Tool  Analysis  [5] 
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Application  and  component 
tags  only  installed  if 
specific  item  is  installed 


Name:  Microsoft  Business  Contact  Manager  2010 

Publisher/Owner:  Microsoft  Corporation 

Version:  14.0.6305.1000 

Abstract:  Contact  management 

UNSPSC  Code:  43232303,  Customer  Relationship  mans 

Tag  type  *  Component 


Name:  Microsoft  SQL  Server  Express  Edition 
Publisher/Owner:  Microsoft  Corporation 


Abstract:  Redistributable  database  se 
UNSPSC  Code:  43232304.  De 
Tag_type  =  Component 


Figure  4:  Diagram  representing  relation¬ 
ship  of  suite,  applications,  components  and 
redistributable  components. 


signature  was  made  during  a  time  period  when  the  certificate 
authority  certifies  the  validity  of  the  digital  signature. 

After  a  SWID  tag  has  been  digitally  signed  and  timestamped, 
a  third  party  can  validate  that  the  SWID  tag  was  provided  by  an 
authoritative  source  during  a  time  when  the  certificate  authority 
indicated  that  the  digital  certificate  was  valid. 

This  level  of  trusted  identification  is  required  by  any  organiza¬ 
tion  that  needs  authoritative  data  about  the  name  of  a  software 
product,  who  published  the  product  and  which  files  the  product 
installed.  In  short,  this  is  the  trusted  identification  information  or¬ 
ganizations  must  have  to  manage  their  IT  environments  securely. 

Summary 

Similar  to  passengers  on  an  airline  being  required  to  identify 
themselves  using  government  issued  identification  documents, 
software  products  require  a  similar  level  of  identification.  SWID 
tags  that  are  digitally  signed  by  the  software  publisher  and  include 
validation  from  a  certification  authority  provide  this  trusted  data. 

Requiring  a  digitally  signed  SWID  tags  provides  the  ability  for 
end-user  organizations  to  validate  that  the  software  they  have 
installed  in  their  organization  are  the  titles  they  expected  and 
that  they  came  from  the  publishers  they  expected  and  not  some 
unknown  publisher. 

2)  Application  Associations 

When  an  individual  flies  on  an  airline  today,  the  airline  must 
ensure  that  the  owner  of  checked  luggage  travels  on  the  same 
flight  as  the  luggage.  Providing  the  association  of  luggage  to  pas¬ 
sengers  is  important  to  airline  security  as  well  as  to  the  passenger 
who  expects  to  have  their  luggage  returned  to  them  at  the  end  of 
the  flight. 

A  typical  Microsoft  Windows  computer  will  have  thousands  of 
executable  files  (*.exe),  and  tens  of  thousands  of  shared  libraries 
(*.dll,  *.ocx,  etc.)  with  a  single  application  potentially  responsible 
for  the  installation  of  hundreds  of  these  executable  files.  Some 
of  these  files  may  be  created  and  owned  by  the  publisher,  some 


may  be  redistributed  versions  of  software  from  another  publisher. 
Today,  it  is  nearly  impossible  to  associate  every  executable  file  with 
its  parent  application.  Additionally,  if  files  from  another  publisher 
are  redistributed,  it  is  impossible  for  the  publisher  of  the  software 
to  validate  that  the  files  in  the  redistribution  package  are  authentic 
without  support  from  SWID  tags. 

TagVault.org  did  an  analysis  of  software  identification  tools  using 
a  very  simple  test  case.  The  test  utilized  different  installations  of 
22  currently  supported,  separately  licensable  products  from  nine 
different  vendors.  The  test  pulled  results  from  six  different  software 
discovery  tools.  The  graphical  results  in  Figure  3  provide  a  clear 
indication  why  application  associations  are  so  critical  to  get  right 
when  dealing  with  software  discovery  data. 

Basically  the  number  of  unique  products  discovered  exploded 
from  what  would  be  a  reasonable  expectation  of  22  different  prod¬ 
ucts  to  a  total  of  700  unique  names  across  the  various  discovery 
tools.  A  large  part  of  this  problem  has  to  do  with  the  fact  that  there 
is  no  consistent  method  to  identify  software  and  the  range  of  op¬ 
tions  produces  wildly  different  collections  of  product  names. 

The  keys  from  a  security  perspective  require  that  a  security 
operations  manager  needs  to  know: 

•  Which  applications  are  related  to  a  particular  bundle  or 
suite  (for  example,  Word,  Excel  and  PowerPoint  are 
applications  that  could  be  stand-alone,  or  part  of  a 
Microsoft  Office  suite). 

•  Which  components  are  related  to  a  particular  applica 
tion  (for  example,  Microsoft  SQL  Server  Express  is  used 
by  Microsoft  Business  Contact  Manager  which  is  a 
component  of  Outlook  which  is  an  application  included  in 
the  Microsoft  Office  Suite). 

•  Validation  that  a  redistributable  component  came  from  a 
known  and  trusted  3rd  party  and  not  some  other,  unknown, 
or  unexpected  entity  (for  example,  was  a  C++  runtime 
library  actually  a  redistributable  library  provided  by  Microsoft). 

SWID  tags  provide  these  capabilities  and  more  through  the 
fact  that  each  publisher  provides  their  own  digitally  signed 
SWID  tags.  When  a  publisher  such  as  Microsoft  provides 
C++  runtime  libraries  in  a  redistributable  package,  they 
provide  a  digitally  signed  SWID  tag  indicating  that  the  C++ 
runtime  is  owned  by  Microsoft  and  the  vendor  that  is  redis¬ 
tributing  the  runtime  can  reference  this  SWID  tag  as  a  “child” 
product  providing  the  association.  By  using  this  method, 
security  operations  can  readily  identify  parent/child  relation¬ 
ships  and  be  able  to  automatically  group  application  and 
component  data  that  would  otherwise  show  up  as  indepen¬ 
dent  applications. 

Obviously,  in  highly  secure  environments,  there  will  be  a 
need  to  validate  these  relationships  and  the  security  of  each 
item,  but  once  validated  the  security  policy  rules  can  be  ap¬ 
plied  to  the  inventory  data  collected  from  all  devices  in  the 
organization. 

Patches  have  a  similar  problem.  When  a  patch  is  released 
by  a  publisher  and  the  organization  determines  that  it  makes 
sense  to  install  the  patch,  the  system  inventory  can  be  used 
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to  immediately  identify  every  device  that  requires  the  patch. 
This  is  due  to  the  fact  that  the  patch’s  SWID  tag  includes 
details  for  which  software  products  it  applies  to.  Obviously, 
validating  that  a  patch  is  installed  is  as  easy  as  checking 
that  the  SWID  tag  for  that  patch  is  installed.  In  highly  secure 
environments,  additional  validations  will  be  applied,  such  as 
ensuring  that  the  publisher’s  name  for  the  patch  matches  the 
publishers  name  for  the  application  being  patched. 

Summary 

Just  like  airlines  have  the  ability  to  associate  a  passenger’s 
checked  bags  with  the  passenger,  software  product  and  com¬ 
ponent  relationships  must  be  detailed  by  the  publisher.  These 
relationships  need  to  be  included  even  if  software  from  a  third  party 
is  included  in  an  application’s  installation  routine.  This  is  not  difficult, 
nor  is  it  expensive  for  publishers  to  provide,  it  simply  has  not  been 
a  requirement  that  software  purchasers  have  made  to  their  vendors. 

Requiring  the  relationships  between  applications  or  components 
to  be  specified  in  SWID  tags  (including  those  that  may  be  redistrib¬ 
ute  from  a  third  party)  ensures  that  security  operations  can  validate 
the  items  are  related  to  each  other  and  that  any  redistributable 
components  were,  in  fact,  provided  by  the  publisher  indicated. 

3)  No  Corruptions  Allowed 

Airlines  must  ensure  that  only  passengers  who  have  pur¬ 
chased  tickets  and  who  have  gone  through  security  screening 
are  allowed  on  a  flight.  It  is  particularly  important  to  validate 
that  there  are  no  unknown  or  high-risk  passengers  allowed  on 
a  flight. 

This  requirement  extends  to  the  files  that  are  installed  by  a 
software  product  on  a  computing  device.  Security  operations 
must  ensure  that  the  files  installed  on  a  device  are  not  cor¬ 
rupted  (i.e.  unknown)  or  malicious  (i.e.  high  risk)  before  install¬ 
ing  and  should  be  able  to  validate  those  details  in  real  time. 

There  are  two  areas  where  file  corruptions  (regardless  if 
they  are  an  accidental  or  malicious)  can  occur  and  must  be 
identified.  The  first  is  on  the  supply  side-being  able  to  validate 
that  the  software  publisher’s  distribution  of  a  software  instal¬ 
lation  package  is  exactly  what  the  publisher  shipped,  and  has 
not  been  modified  by  a  man  in  the  middle  attack,  is  critical  to 
secure  systems.  In  these  cases,  a  SWID  tag  with  the  complete 
installation  file  manifest  that  is  digitally  signed  by  the  publisher 
and  that  includes  secure  hash  values  for  every  file  is  required. 
This  allows  an  organization  to  validate  that  the  files  shipped  by 
the  publisher  are  exactly  the  same  as  the  files  received  by  the 
organization  with  no  modifications. 

The  second  issue  dealing  with  file  corruptions  has  to  do 
with  ensuring  files  that  are  installed  on  a  device  for  a  software 
product  are  known  files  that  are  not  corrupted.  In  this  case, 
the  SWID  tag  must  include  a  digitally  signed  file  manifest  that 
includes  a  secure  file  hash  as  part  of  the  file  list.  Obviously, 
some  files  that  are  installed  for  a  software  title  will  be  modi¬ 
fied  once  installed  (configuration  options,  data  files,  etc.)— and 
these  files  cannot  include  a  trusted  secure  hash,  however,  at 
a  minimum,  the  executable  files  for  an  application  must  be 
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Figure  5:  Conceptual  graphic  of  file 
manifest  used  to  identify  malicious 
executable  files. 


included  in  the  manifest  and  must  include  a  hash  that  can  be 
validated. 

Some  software  components  (for  example,  Windows  device 
drivers)  need  to  be  digitally  signed  for  the  operating  system 
to  trust  them.  Unfortunately,  as  was  seen  with  the  Stuxnet 
malware,  simply  requiring  a  digital  signature  for  the  operating 
system  to  trust  a  driver  is  not  sufficient.  In  the  case  of  Stuxnet, 
the  drivers  that  were  part  of  the  malware  payload  were  digitally 
signed,  but  were  signed  by  a  publisher  other  than  the  publisher 
that  provided  the  software  [6].  If  the  software  had  included  a 
digitally  signed  manifest  from  the  publisher,  it  would  have  been 
significantly  more  difficult  for  the  Stuxnet  malware  to  avoid  de¬ 
tection  as  the  changes  it  made  to  the  application  by  replacing 
a  core  shared  library  with  a  malicious  one,  would  have  been 
detectable  by  ISO  19770-2  compliant  scanning  tools. 

Summary 

Just  as  airlines  and  security  requirements  would  not  allow  un¬ 
known  people  or  unscreened  baggage  onto  a  commercial  flight, 
IT  Security  Managers  should  not  allow  unknown  applications 
or  executable  files  to  be  installed  on  their  network.  The  details 
required  to  securely  provide  file  manifests  for  software  instal¬ 
lation  media  as  well  as  executable  files  that  are  installed  on  a 
device  are  not  difficult  or  expensive  to  provide  if  the  process  to 
create  the  manifest  is  integrated  into  a  product  build  cycle.  The 
only  organization  that  can  do  this  in  any  cost  effective  manager 
is  the  publisher  themselves. 

Requiring  SWID  tags  with  secure  file  manifests  to  be  included 
as  part  of  the  installation  media  (to  ensure  supply  side  security 
of  the  distributed  files)  as  well  as  for  the  installed  software 
allows  security  operations  to  validate  applications,  components 
and  patches  to  any  level  of  detail  required. 

4)  No  Known  Threats 

Airlines  would  not  allow  passengers  to  board  with  carry  on  or 
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checked  luggage  that  contained  dangerous  materials.  All  baggage  is 
screened  to  validate  that  potential  risks  to  any  flight  are  minimized. 

The  software  environment  in  most  IT  operations  is  much  more  dy¬ 
namic  than  is  the  case  for  a  piece  of  luggage  that  can  be  screened 
once  and  assumed  to  remain  safe  as  long  as  it  remains  in  a  secure 
environment.  With  higher  complexity  levels  inherent  in  today’s  soft¬ 
ware,  publishers  are  regularly  providing  patches  and  updated  con¬ 
figuration  guidance  to  minimize  the  potential  for  security  breaches. 
Unfortunately,  the  process  by  which  patches  and/or  configuration 
changes  can  be  identified  as  being  required  is  often  a  very  manual 
and  time  intensive  process. 

Patches  to  software  products  must  have  the  same  type  of  secure 
file  manifest  provided  so  that  as  the  patch  changes  an  executable 
file,  security  monitoring  systems  can  identify  that  a  patch  made  the 
change  and  it  is  not  due  to  a  potentially  malicious  change  to  a  file. 

The  requirement  to  include  secure  file  manifests  with  applications, 
components  and  patches  provides  a  very  positive  side-effect  that 
can  be  easily  implemented  for  IT  environments—  organizations  have 
enough  data  that  IT  processes  can  validate  that  any  of  these  items 
are,  in  fact,  installed  on  a  device.  If  the  SWID  tag  is  installed  on  a 
device  and  it  contains  a  secure  manifest,  a  process  can  validate  if  the 
files  are  actually  installed. 

Summary 

Just  as  all  baggage  destined  to  fly  on  a  commercial  airplane 
must  be  screened  and  declared  safe,  software  must  be  vali¬ 
dated  to  ensure  it  is  up-to-date  with  no  outstanding  patches  or 
configuration  changes  required.  This  can  be  done  by  ensuring 
that  patches  identify  the  software  products  they  are  targeted 
at  as  well  as  by  providing  secure  file  manifests  to  identify  that 
a  specified  publisher  provided  the  patch  and  that  the  files  have 
not  been  modified. 

Requiring  patches  to  include  SWID  tags  will  not  add  to  the 
complexity  or  cost  of  software  development  efforts  if  the  pro¬ 
cedures  are  integrated  into  the  proper  process  of  a  patch  build 
environment.  The  benefits  to  end-user  organizations  and  tools 
that  manage  IT  operations  are  very  significant  and  can  allow  a 
much  higher  degree  of  security  that  simply  is  not  possible  today. 

Secure  Software  Requires  Secure  SWID  Tags 

IT  environments  today  are  getting  more  and  more  complex. 
With  this  complexity,  cyber  security  issues  related  to  software 
installations,  patches  and  configurations  are  skyrocket¬ 
ing.  With  commercial  organizations,  national  infrastructure 
systems  and  national  security  related  systems  becoming 
increasingly  connected,  it  is  clear  that  software  must  include 
a  trusted  and  authoritative  identification  capability  in  a  stan¬ 
dardized,  normalized  format.  The  cross  platform  (Windows, 
UNIX,  Linux,  Mac)  and  cross  vendor  capabilities  enabled  by 
the  ISO/IEC  19770-2:2009  Software  Identification  Tag¬ 
ging  standard  must  be  embraced  by  the  software  engineer¬ 
ing  community  as  a  software  assurance  best  practice  for 
commercial  and  internally  developed  applications.  Until  the 
community  makes  these  requirements,  IT  environments  will 
continue  to  struggle  with  effectively  managing  and  securing 
their  software  applications. 
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Upcoming 
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Visit  <http://www.crosstalkonLine.org/events>  for  an  up-to-date  list  of  events. 


Software  Assurance  Forum  -  March  2013 

5-7  March  2013 
Gaithersburg,  MD 

https://buildsecurityin.us-cert.gov/bsi/ 
events/1 41 7-BSI.html 


Government  Contracting 

12-13  March  2013 


Washington,  DC 

http://publiccontractinginstitute.com/events 

Conference  on  Systems  Engineering 

Research 

19-22  March  2013 

Atlanta,  GA 

http://cser1 3. gatech.edu 

7th  International  Symposium  on  Service 
Oriented  System  Engineering 

25-28  March  2013 
San  Francisco,  CA 

http://sei.pku.edu.cn/conference/sose201 3 

Symposium  of  Mobile  Cloud,  Computing, 
and  Service  Engineering 

25-28  March  2013 
Redwood,  CA 

http://www.engr.sjsu.edu/gaojerry/ 
IEEEMobileCloud201 3/index.htm 

Software  Technology  Conference 

8-11  April  2013 

Salt  Lake  City,  UT 

http://www.sstc-online.org 

7th  Annual  IEEE  Systems  Conference 

15-18  April  2013 
Orlando,  FL 
http://ieeesyscon.org 


Cloud  Computing  and  Assurance  for 
Critical  DoD  Initiatives 

23- 25  April  2013 
Washington,  DC 

http://www.marcusevans-conferences- 
northamerican.com/cloud_201 3 

Systems  Engineering,  Test  and  Evalua¬ 
tion  Conference 
29  April  -  1  May  2013 
Canberra,  Australia 

http://sapmea.asn.au/conventions/sete201 3 

IBM  Edge  2013 

10-14  Jun  2013 

Las  Vegas,  NV 

http://www.ibm.com/edge 

23rd  Annual  INCOSE  International  Sym¬ 
posium 

24- 27  Jun  2013 
Philadelphia,  PA 

http://www.incose.org/symp201 3 

Software  Assurance  Working  Group  Ses¬ 
sions 

25- 27  Jun  2013 
McLean,  VA 

https://buildsecurityin.us-cert.gov/bsi/events.html 
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Once  again,  I  find  myself  writing  a  BackTalk  column  sitting  in 
an  airplane.  I  live  about  two  hours  from  an  airport  so  between 
the  joys  of  getting  up  early  on  a  Saturday,  traffic,  airport  parking, 
crowded  check-in  lines,  totally  full  flight,  and  only  a  one-hour 
delay  in  taking  off— I  am  just  in  a  great  mood. 

Back  in  the  day,  this  column  was  not  called  “BackTalk.”  It  was 
called  “The  Curmudgeons’  Corner.”  A  curmudgeon  is  defined  as 
a  killjoy,  wet  blanket,  or  a  grouch.  This  column  was  a  place  to  air 
gripes  and  general  displeasure  about  software,  bureaucracy,  and 
the  general  process  of  producing  software.  There  used  to  be 


several  authors— and  all  of  us  were  grouchy.  Over  time,  several 
of  the  authors  decided  to  pursue  other  areas  of  literary  achieve¬ 
ment.  You  know  what  I  think?  They  ran  out  of  things  to  gripe 
about.  Luckily,  the  publishers  still  have  me  around.  I  can  always 
find  something  to  complain  about-such  as  change. 

The  story  goes  that  a  new  assistant  at  a  grocery  store  noticed 
that  hardly  anybody  was  buying  rutabagas.  It  was  the  lowest- 
selling  item  in  the  produce  department.  He  decided  to  remove 
the  entire  display  of  rutabagas.  When  the  general  manager  no¬ 
ticed  that  the  rutabagas  were  missing,  he  spoke  to  the  assistant 
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and  asked  why.  The  assistant  explained,  and  expected  the  gen¬ 
eral  manager  to  compliment  him.  Instead,  the  general  manager, 
with  an  irritated  look,  asked,  “Well,  why  stop  there?  After  all,  now 
something  else  is  the  lowest-selling  item!” 

With  that  epiphany,  the  assistant  realized  that  he  could  always 
remove  the  lowest-selling  vegetable,  until  nothing  was  left  but 
apples  and  unhappy  customers.  With  this  realization,  rutabagas 
were  restored,  and  the  system  was  left  the  way  it  was.  Leaving 
things  the  way  they  are  does  not  imply  you  do  not  care-it  might 
also  mean  that  the  current  system  works  well  enough. 

Back  in  1998, 1  became  a  Personal  Software  Process  (PSP) 
instructor.  I  had  to  take  the  class  (and  pass!)  before  I  could  be 
certified  to  teach.  Overall,  I  learned  a  lot,  and  my  coding  quality 
and  speed  really  improved.  Part  of  the  process  was  submitting  a 
Process  Improvement  Proposal  (PIP)  every  time  as  I  completed 
the  exercises.  The  PIP  was  to  force  me  to  come  up  with  an  im¬ 
provement  on  my  personal  process  for  developing  software.  And 
I  rebelled.  I  submitted  several,  but  eventually  I  reached  the  point 
where  I  was  pretty  happy  with  my  own  process,  and  did  not 
really  see  a  critical  need  to  improve.  Nevertheless,  my  instruc¬ 
tor  demanded  that  I  submit  a  suggested  improvement  for  each 
remaining  program.  As  I  remember,  my  last  few  improvement 
proposals  consisted  of  things  like,  “Keep  a  pencil  sharpener 
closer  to  my  desk,”  “Use  higher-wattage  bulbs  during  design,” 
and  my  all-time  favorite,  “Stock  up  on  beverages,  chips  and 
popcorn  prior  to  coding.”  I  eventually  passed-and  am  still  pretty 
pleased  with  my  coding  process. 

I  am  not  saying  PSP  did  not  help  me— it  did.  What  I  am  saying 
is  that  eventually  I  reached  a  point  where  things  worked  for 
me.  Why  change  what  works?  When  you  modify  a  process,  it 
involves  risk.  The  risk  of  changing  things  is  that  somebody  might 


be  less  satisfied.  Here  are  two  similar  “risk  rules”  I  have  learned 
over  the  years: 

1.  You  cannot  make  all  the  customers  happy.  In  fact,  you  really 
probably  cannot  make  most  of  them  happy.  What  you  can  do 

is  try  not  to  make  too  many  of  them  very  unhappy.  Sometimes, 
nobody  is  happy.  But  perhaps  few  are  miserably  unhappy. 

2.  For  customers,  it  is  much  easier  to  wait  until  a  change 
occurs  and  then  complain,  rather  than  being  proactive  about 
what  they  need  up  front.  There  are  lots  of  reasons  for  this— but 
the  main  issue  is  that  customers  do  not  really  know  what  they 
want— but  they  are  quick  to  realize  what  they  do  not  want. 

Sometimes  the  best  thing  to  do  is  to  change  nothing! 

Those  of  us  who  work  for  the  government  or  any  large 
organization  know  the  golden  rule  of  change,  “Change  is 
often  substituted  for  progress.”  Need  to  look  occupied? 

For  heaven’s  sake,  change  something.  Cannot  find  something 
to  change?  Then  it  is  probably  time  to  reorganize.  To  the 
outsider,  it  looks  like  progress. 

Do  not  wake  a  sleeping  baby.  Do  not  change  a  process  that 
minimizes  the  number  of  unhappy  customers.  Sometimes  the 
least  damage  you  can  do  is  not  change  a  single  thing.  Before 
making  changes,  weigh  the  advantages  of  leaving  things  the 
way  they  are.  It  might  make  some  customers  unhappy,  but  it  also 
might  make  less  of  them  very  unhappy  than  any  other  action.  You 
are  not  being  complacent-you  are  being  passively  proactive! 

And  I  plan  on  being  a  curmudgeon  for  a  long,  long  time. 

David  A.  Cook 

Stephen  F.  Austin  State  University 

cookda@sfasu.edu 
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above  organizations  for 
providing  their  support. 
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Software  Assurance 


Software  is  essential  to  enabling  the 
nation’s  critical  infrastructure. 

To  ensure  the  integrity  of  that  infrastructure,  the 
software  that  controls  and  operates  it  must  be 
secure  and  resilient. 

Software  Assurance  Community  Resources  and 
Information  Clearinghouse  provides  corroboratively 
developed  resources.  Learn  more  about  relevant 
programs  and  how  you  can  become  involved. 


Security  must  be  “built-in”  and 
supported  throughout  the  lifecycle. 

Visit  https://buildsecurityin.us-cert.gov  to  learn 
about  the  practices  for  developing  and 
delivering  software  to  provide  the  requisite 
assurance.  Sign  up  to  become  a  free 
subscriber  and  receive  notices  of  updates. 

The  Department  of  Homeland  Security 
provides  the  public-private  collaboration 
framework  for  shifting  the  paradigm  to 
software  assurance. 
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